- edited description
Confidentiality of Self-Issued OP response
For Self-Issued OpenID Providers as native applications, the response to the RP is not passed to the browser in a redirect, but by OS specific means. As of now, the Self-Issued OP Specification does not specify the properties required for this step.
In particular, we have a problem if an attacker can register an application they control as a handler for the RP redirect_uri on the End-Users device. Then the attacker might obtain a 'fresh' valid ID token with the RP in the audience for an identity of the End-User.
For a more detailed description, please see the writeup in the attached pdf.
Comments (7)
-
reporter -
-
- changed status to resolved
Merged in siop-v2-response-confidentiality (pull request #119)
fixes
#1425- adds security consideration for confidentiality response (same-device)Approved-by: Torsten Lodderstedt Approved-by: Daniel Fett Approved-by: Kristina Yasuda
→ <<cset 290f3296991e>>
-
- changed status to open
I am not sure why merging the PR automatically closed this issue (maybe because it was in the title)
Reopening this, since during SIOP call I understood that there are more PRs expected to reflect findings in the attached pdf.
-
does this attack require the attacker having its own browser app? why identifying “a good browser“ is relevant?
-
reporter It requires to have any app controlled by the attacker on the users device that can claim to handle the redirect_uri of a good SIOP (e.g. with a deep-link without the verification of the App Link in Android).
-
- changed status to resolved
Migrated to GitHub
- Log in to comment