Howdy DW, Thanks very much for your response! It's totally understandable that the authorization server should ask for re-confirm if the refresh_token is no longer valid, and it's also understandable that if you're using implicit flow with only an access_token that you don't need to ask for re-confirm every time.
However, I'm specifically interested in authorization code flow situations where an authorization request is made despite the client already having a valid grant. It's an atypical request for the client to make, since they theoretically should already have valid access/refresh_tokens, but when it does happen, what is the authorization server supposed to do? Is it bad for them to auto-redirect back with another authorization code without asking the user to confirm again? Shouldn't they treat the authorization request the same way they treat all other authorization requests (by asking for user confirmation)? It seems there are situations where this transparent redirect behavior can be dangerous[1][2] or misleading[3]. [1]: Issuing a new authorization code without requiring confirmation from the user is what allowed Github's HEAD exploit to be practical because it allowed the client to exfiltrate the authorization code without user interaction. Had Github always requested user to click Allow, even though the user would have already granted access through the HEAD exploit, the client wouldn't be able to obtain the authorization code without user interaction. I understand that fixing the HEAD exploit in the first place is the first and best solution, but the lack of user interaction is what elevated this exploit from high to critical. [2]: For users that have multiple accounts with a client (e.g. personal, anonymous, work, etc.), if an authorization server auto-redirects for repeated authorization requests, once that user connects one account via OAuth to the client, the client can then attempt authorization requests for other accounts and see which ones get auto-redirect back. This can, without user interaction, potentially de-anonymize or map different accounts on the client to the same user that the user didn't necessarily want to be mapped. [3]: Privacy regulations are adding more and more for users to "opt-in" to various types of data access or data sharing, and sometimes consent requirements for the client don't line up with the expiration/revocation timelines of the authorization server (e.g. clients may be required to get an opt-in annually, even if the authorization server grant never expires). Clients are assuming that using the redirect back with an authorization code is proof of consent for their privacy compliance records (it is called Open Authorization, after all). However, with transparent redirects in the authorization code flow, this isn't necessarily true and you can no longer rely on OAuth as a valid mechanism for proving user consent. I realize that it's open to the authorization server to issue authorization codes how they see fit. It just strikes me as odd that there's not a lot of guidance around when transparent redirects are safe, when user interaction should occur, and the risks and implications of both behaviors. Daniel Roesler Co-founder & CTO, UtilityAPI dan...@utilityapi.com On Fri, Nov 8, 2019 at 2:02 PM David Waite <da...@alkaline-solutions.com> wrote: > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
