Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"

[Daniel Roesler <[e-mail]>]

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
[e-mail]
On Fri, Nov 8, 2019 at 2:02 PM David Waite <[e-mail]> 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=[e-mail]> 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
> > [e-mail]
> >
> >
> >
> > On Wed, Nov 6, 2019 at 2:27 AM Hannes Tschofenig
> > <[e-mail]> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth