- changed status to open
Id mix up attack
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.
Comments (14)
-
-
reporter 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)
-
reporter 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
-
we discussed improving the wording to make it clear what session refers to.
-
reporter both that it is a browser session and what action starts the session
-
reporter 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
-
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 sameclient_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 uniqueredirect_uri
, storing it before each session, and then comparing the current callbackredirect_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 theredirect_uri
in the authorization request does not match any of the registered ones and return an error. The use of arequest
object orrequest_uri
in the authorization request will prevent tampering with the request parameters and the use of a hybrid flow will bind the current session'sstate
parameter to ID Token via the ID Token'ss_hash
claim. -
Part 2: Re:
#91among other security considerations.→ <<cset d6bf05358e8e>>
-
Clarify "session"
-
-
- changed status to resolved
Fixed
#91by clarifying "sessions".→ <<cset 3167b684b5f3>>
-
- changed component to Part 2: Advanced
-
- changed component to FAPI 1 – Part 2: Advanced
-
- changed component to FAPI 1: Advanced
- Log in to comment
For Hybrid flow of OpenID Connect, you need to do nothing.
Otherwise, you need to do it. What you have to do is: