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

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
daniel@utilityapi.com

On Wed, Nov 6, 2019 at 2:27 AM Hannes Tschofenig
<Hannes.Tschofenig@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