Open OIDF-automation opened 2 years ago
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>>
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?
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).
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.