Id mix up attack

[Tom Jones]

I frankly do not understand how to implement the following from this section. Is the implication that only dynamic registration will provide the functionality?And by implication that this applies to a secure implementation of OpenID Connect as well?

By registering a unique redirect_uri, storing it before each session, and then comparing the current callback redirect_uri to that stored in the session, the client can mitigate this attack.

[Nat Sakimura]

For Hybrid flow of OpenID Connect, you need to do nothing.

Otherwise, you need to do it. What you have to do is:

1. For each AS that you support, create a unique Redirection URI.
2. Register the URI either through the developer console of the AS or through the dynamic registration.
3. Before sending an authorization request, store the value of the Redirection URI in the browser session.
4. When the response comes back, check that the URI that is stored in the browser session is the same as the one you are receiving the response.

[Tom Jones]

What I don't understand here is the concept of session. Since my rp supports multiple overlapping requests, I cannot know when a session completes. Nor can I know when to start a new one.

thx ..Tom (mobile)

[Tom Jones]

An additional complication is the Microsoft identity stack. I will check, but I fear that I would need to rewrite even more of that than I planned. ..t

[Dave Tonge]

we discussed improving the wording to make it clear what session refers to.

[Tom Jones]

both that it is a browser session and what action starts the session

[Tom Jones]

another point of clarification on the meaning of unique redir. Is it possible for the uniqueness to be limited to the query string? I know that some addresses allow this, but i am not clear if that is possible here. So the redir address would be: https://somesite.com/endpoint?uniquevalue=randomstuff

..tom

[Nat Sakimura]

Actually, what is written as the mitigation in current 8.5 Mix-up attack does not pertain to the Part 2 since it is mitigated by the use of the hybrid flow to start with. What was written there only applies to a pure RFC6749.

So, I will rewrite it in that spirit. The current text is more relevant to Part 1.

FYI, the current text is as follows:

8.5 IdP Mix-up attack

In this attack, the client has registered multiple IdPs and one of them is a rogue IdP that returns the same client_id that belongs to one of the honest IdPs. When a user clicks on a malicious link or visits a compromised site, an authorization request is sent to the rogue Idp. The rogue Idp then redirects the client to the honest IdP that has the same client_id. If the user is already logged on at the honest IdP, then the authentication may be skipped and a code is generated and returned to the client. Since the client was interacting with the rogue IdP, the code is sent to the rogue IdP's token endpoint. At the point, the attacker has a valid code that can be exchanged for an Access Token at the honest IdP. By registering a unique redirect_uri, storing it before each session, and then comparing the current callback redirect_uri to that stored in the session, the client can mitigate this attack. At the same time, the honest IdP will be able to detect that the redirect_uri in the authorization request does not match any of the registered ones and return an error. The use of a request object or request_uri in the authorization request will prevent tampering with the request parameters and the use of a hybrid flow will bind the current session's state parameter to ID Token via the ID Token's s_hash claim.

[Nat Sakimura]

Part 2: Re: #91 among other security considerations.

→ <<cset d6bf05358e8e>>

[Nat Sakimura]

Clarify "session"

[Nat Sakimura]

Re: https://bitbucket.org/openid/fapi/issues/91/id-mix-up-attack#comment-36702383

Yes.

[Nat Sakimura]

Fixed #91 by clarifying "sessions".

→ <<cset 3167b684b5f3>>