Support for RFC 9207 — OAuth iss parameter

[ThisIsMissEm]

Pitch

In order to further securing OAuth flows for Mastodon, once we have PKCE (#30329) implemented, we should consider supporting RFC 9207 which adds an iss response parameter to the OAuth authorization code redirect, allowing clients to safely assert that the code comes from the authorization server that they believe they're interacting with.

Motivation

At present, applications either don't do such an assertion that they've been redirected back from the same authorization server, or they rely on some form of cookie and referrer tracking. This provides a first party mechanism for verification.

Arguably, what this guards against is protected by PKCE as far as I can tell, but it'd also allow clients to not acccidentally exchange the code + challenge_verifier with a malicious Authorization Server accidentally (e.g., session mix up leads to the state not fully matching)

[ThisIsMissEm]

This is currently recommended for setups where clients talk to multiple authorization servers as a security best practice. See 4.4.2.1. Mix-Up Defense via Issuer Identification

[FenTiger]

Arguably, what this guards against is protected by PKCE

In the context of my experimental single sign-on system the following attack is possible:

• The attacker sets up a configuration referring to the victim's real auth endpoint and his own, malicious token endpoint.
• The attacker somehow convinces the victim to log in using a maliciously constructed ID instead of the victim's real ID. (In some cases, this can be done by tricking the victim into following a malicious link.)
• I contact the victim's auth endpoint, retrieve an auth code, and then forward it to the attacker's token endpoint. Whoops!

RFC9207 allows me to protect against this. PKCE does not, because the attacker receives the code_verifier at the same time as he receives the auth code, so he is able to forward both to the real token endpoint and receive an access token.

Right now, in the Mastodon case, I protect against this by checking that the auth endpoint, the token endpoint and (just for good measure) the app_registration_endpoint are all on the same domain as the issuer ID. This limits flexibility and also isn't part of any OAuth2/OIDC standard as far as I'm aware.

Edit: I've just realised that this is actually what you said in the rest of that paragraph. Doh! I'll leave this comment here, though, in case someone finds it helpful, and also just to record that I think this feature should be implemented.