OAuth Profile should mandate per AS redirect URI for Clients with session comparison

[Nat Sakimura]

To mitigate Mix-up attack, OAuth profile should mandate the clients to

1. use separate Redirect URI for each AS it is talking to;
2. store the redirect URI in the browser session and compare it with the URI the authorization response was sent to.

[Dave Tonge]

@Nat do you have a reference to session comparison? Are you referring to the state param - https://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-10.12 or are you referring to mitigating mix-up: https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-01

[Sascha Preibisch]

Is it not difficult to use different redirect_uri's? A client (web client) is usually running on one URI. Or are more details required for this ticket?

[Nat Sakimura]

@SaschaZeGerman, OAuth Frameworks basic security premise is that a client only talks to one server. If the client talks to multiple servers, then it has to have its "virtual" instances. This means that the client MUST have different redirect_uris for each Authorization Server. Otherwise, the client is prone to code injection attack also known as IdP mix-up attack.

It is the consensus of the OAuth WG after a year of heated discussion that it has to have separate Redirection URIs. Note: a URI includes query parameters as well. So, it is trivial to support separate Redirection URIs for each authorization server AS1, ... , ASn by doing like:

AS1: https://client.example.com/callback?as=AS1 ... ASn: https://client.example.com/callback?as=ASn

[Nat Sakimura]

@dgtonge , sorry for a tardy reply.

The reference, to some extent, is https://tools.ietf.org/html/rfc6819#section-4.4.1.8

The mix-up attack is described in https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-01 , but the solution it proposes is not what the people (including me) came to at the Trier meeting, which was more or less the same as I was suggesting. (I was put in as one of the author for the document as I kept complaining about the direction the draft was going that it is not addressing the real issue.) My blog post https://nat.sakimura.org/2016/07/20/fixing-oauth/ talks about what we came to in the meeting.

[Sascha Preibisch]

@Nat I now understand your multiple redirect_uri approach. Your examples show the client running on the same domain but with different parameters. I get that. I was thinking the idea would be to have the same client running on different domains which would not make too much sense to me. This also works fine with the RFC 6749 which allows clients to register multiple redirect_uri's

[Nat Sakimura]

So, can I close this ticket? > Sascha

[Sascha Preibisch]

#12, understood, no questions

[Sascha Preibisch]

Please close this ticket