Our current Authorization Flow handles redirect_uri incorrectly. Right now, clients send a redirect_uri to /v1/oauth2/authorize, we respond with a redirect, and then the client includes the same redirect_uri again at token exchange to validate the flow. This puts validation in the wrong place and allows unsafe behavior.
Problem
- What’s wrong: We rely on the
redirect_uri during the token exchange to validate the authorization.
- Why it’s a bug:
redirect_uri must be validated up front at the authorization request against the client’s pre-registered redirect URI. The token endpoint should not depend on a client-supplied redirect_uri for trust decisions (and should never switch clients based on it).
Expected Behavior
- Each OAuth client has a pre-registered redirect URI stored in our database.
- On GET and POST
/v1/oauth2/authorize, the server:
- Requires
client_id.
- Validates the
redirect_uri exactly against the client’s registered URI before issuing any redirect or auth code.
- The token endpoint does not use
redirect_uri to select or validate the client. The authorization code is sufficient to bind the transaction to the original, validated redirect.
Our current Authorization Flow handles
redirect_uriincorrectly. Right now, clients send aredirect_urito/v1/oauth2/authorize, we respond with a redirect, and then the client includes the sameredirect_uriagain at token exchange to validate the flow. This puts validation in the wrong place and allows unsafe behavior.Problem
redirect_uriduring the token exchange to validate the authorization.redirect_urimust be validated up front at the authorization request against the client’s pre-registered redirect URI. The token endpoint should not depend on a client-suppliedredirect_urifor trust decisions (and should never switch clients based on it).Expected Behavior
/v1/oauth2/authorize, the server:client_id.redirect_uriexactly against the client’s registered URI before issuing any redirect or auth code.redirect_urito select or validate the client. The authorization code is sufficient to bind the transaction to the original, validated redirect.