Hello Daniel! > 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).
> 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. OAuth does not provide a way to recover from an expired access token barring a refresh token, which also can be invalidated. In particular, the only front channel ‘continuation’ parameter I know of is ‘id_token_hint’ in OIDC. There are deployments today (admittedly mostly using implicit flow) which do not have refresh tokens. A mandate that you SHOULD ask for re-consent would be a recommendation that they have to interrupt the user periodically to continue access - which would just create another security vs usability decision. Per your point above, the actual security issue was that GitHub 1) had the authorization endpoint serve double-duty and 2) treated HEAD requests as a quasi GET/POST to create a grant in their database to the client without user confirmation. The solution for this is not to ask the user to re-confirm on every request.. That said, it does make sense for some deployments to periodically invalidate a refresh token, even for the purpose of bringing the user back to re-consent permissions (aka self-audit). An application could theoretically distinguish from tokens granted by the protected user needing to be invalidated to drive the user to re-consent, and operationally granted tokens which are assumed to be actively managed and not tied to any user account. -DW > On Nov 8, 2019, at 5:49 AM, Daniel Roesler > <daniel=40utilityapi....@dmarc.ietf.org> wrote: > > 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: > > > 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. > > > [1]: https://blog.teddykatz.com/2019/11/05/github-oauth-bypass.html > > Daniel Roesler > Co-founder & CTO, UtilityAPI > dan...@utilityapi.com > > > > On Wed, Nov 6, 2019 at 2:27 AM Hannes Tschofenig > <hannes.tschofe...@arm.com> 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 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
