Howdy, In the "3.1 Protecting Redirect-Based Flows" > "3.1.1. Authorization Code Grant" section, is there guidance on when it is appropriate (if ever) to automatically generate a new authorization code and redirect back to the client?
A recent exploit[1] on Github's OAuth implementation was practical because if you make an authorization request and the resource owner is already authenticated and the scope is already authorized, Github will silently generate a new authorization code and redirect the user back to the redirect_uri without asking them to click "Authorize" again. How the exploit worked: 1. The client makes an ajax HEAD request to the OAuth authorization endpoint, which will silently create the authorization grant (this was the security exploit that was patched). 2. However, since the ajax response was blocked via CORS, the client couldn't receive the authorization code in the response parameters. 3. So, the client then redirected the user to Github's authorization endpoint with the same authorization code request (only this time as a real GET redirect). 4. Github instantly redirected the user back to the client's redirect_uri with a new authorization code and without asking for any user interaction. It seems strange to me that OAuth should allow for transparent authorization code redirects without resource owner confirmation. This situation only comes up when something weird is happening, such as when a client loses their valid access|refresh_token, but isn't that all the more reason to clarify that you should always ask for resource owner confirmation of the scope, even in scenarios where you are just re-authorizing the same scope as before? Had Github asked for confirmation on step 4 above, the practicality of the HEAD exploit would have been reduced because the user would have been presented with an unexpected Allow/Deny Github OAuth dialogue, possibly alerting them to the fact that something strange was going on. Anyway, I'm trying to find guidance on transparent redirects for authorization code grants. There's a whole host of both security and application logic issues that could come up from such behavior, so I'd like to ask for clarification in best practices. [1]: https://blog.teddykatz.com/2019/11/05/github-oauth-bypass.html Daniel Roesler Co-founder & CTO, UtilityAPI [email protected] On Wed, Nov 6, 2019 at 2:27 AM Hannes Tschofenig <[email protected]> wrote: > > Hi all, > > this is a working group last call for "OAuth 2.0 Security Best Current > Practice". > > Here is the document: > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13 > > Please send you comments to the OAuth mailing list by Nov. 27, 2019. > (We use a three week WGLC because of the IETF meeting.) > > Ciao > Hannes & Rifaat > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
