-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Confidentiality of Self-Issued OP response #7
Comments
Imported from AB/Connect bitbucket - Original Commenter: danielfyes |
Imported from AB/Connect bitbucket - Original Commenter: KristinaYasudaMerged in siop-v2-response-confidentiality (pull request #119) fixes #1425 - adds security consideration for confidentiality response (same-device) Approved-by: Torsten Lodderstedt → <<cset 290f3296991e>> |
Imported from AB/Connect bitbucket - Original Commenter: KristinaYasudaI 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. |
Imported from AB/Connect bitbucket - Original Commenter: KristinaYasudadoes this attack require the attacker having its own browser app? why identifying “a good browser“ is relevant? |
Imported from AB/Connect bitbucket - Original Commenter: chrisibaIt 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). |
Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1425
Original Reporter: chrisiba
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.
The text was updated successfully, but these errors were encountered: