- changed status to open
IdP Confusion Attack
This is one of the attack cases listed in the report SoK: Single Sign-On Security – An Evaluation of OpenID Connect
In this attach, the Attacker OP forces the Client to send valid "code" issued by the Honest OP to the Attacker OP.
The attacker OP returns the same "client_id" during the registration as the one registered at the Honest OP. In other words, the Client has same client_id on both OPs. Execution.
Step 1: Attacker starts an authentication on the Client with the Honest OP. It caches the received "state" and "nonce" parameters sent to the Authentication Request.
Step 2: Attacker starts an authentication on the Client with the Malicious OP.
Step 3: Malicious OP receives the Authentication Request and responds with a HTTP 302 Redirect to the Honest OP. The redirect URL contains the same parameters received in the Authentication Request except the "nonce" parameter, which is replaced by the value from Step 1.
Result Evaluation. The attack is successful if the Malicious OP receives the "code" generated by the Honest OP in the Token Request.
Comments (8)
-
-
Add brief description in the intro, and details in the security considerations in Part 2.
-
Are not confidential clients covered as the attacker cannot use
code
since he has no client secret?Why would a public client use dynamic registration?
This attack needs to be able to insert
nonce
in the authorization request. By using request object, it becomes impossible.But is this a valid attack?
-
- marked as enhancement
- marked as minor
-
- changed status to closed
-> <<cset ee0270f>>
-
- changed component to Part 2: Advanced
-
- changed component to FAPI 1 – Part 2: Advanced
-
- changed component to FAPI 1: Advanced
- Log in to comment
We are good with request object and hybrid mode as well. Return to has to be different for each OP.