FAPI2: Specify that redirect_uri's must be exact match

[Joseph Heenan]

Whilst discussing https://bitbucket.org/openid/connect/issues/2045/certification-proposed-change-to-how Nat mentioned that he’s not sure that OAuth is sufficiently explicit that redirect_uri must exactly match the registered one, and we should consider adding a clause to FAPI2 to require exact matching.

[Aaron Parecki]

Never hurts to be more explicit, this is what OAuth 2.0 has in the Security Considerations section: https://datatracker.ietf.org/doc/html/rfc6749#section-10.6

If a redirection URI is provided
in the request, the authorization server MUST validate it against the
registered value.

We moved similar language way up higher in the doc in OAuth 2.1, and made it even more explicit

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-09#section-2.3.1

Authorization servers MUST reject authorization requests that specify a redirect URI that doesn't exactly match one that was registered

‌

[Tim Würtele]

I’d also like to point out that PAR (RFC 9126) explicitly allows the use of unregistered redirect URIs (with a MAY). Section 2.1 has the following to say:

The authorization server MAY allow clients with authentication credentials to establish per-authorization-request redirect URIs with every pushed authorization request.

and Section 2.4 (which is about redirect URIs) is even more explicit:

The authorization server MAY allow [...] clients to specify redirect_uri values that were not previously registered with the authorization server.

Therefore, the formal analysis allowed clients to use arbitrary redirect URIs in their PAR request.

However, if the flexibility of non-registered redirect URIs is not needed, it certainly makes sense to mandate exact matching of registered values.

[Aaron Parecki]

I don't know if this ended up in the Security BCP or only OAuth 2.1, but there is language roughly to the effect of a PAR request with client authentication is one way to register a redirect URI. The justification is because this is a backchannel request and an attacker can't set an arbitrary value in that case.

[Dave Tonge]

Closing, as FAPI2 requires PAR which allows arbitrary redirect_uris and this has been considered by the security analysis