Timeline for OAuth 2.0 POST to Authorization Endpoint
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 7, 2022 at 10:43 | comment | added | Cochise Ruhulessin | 1) The end-user authenticates with Ident and obtains a JWT, 2) The JWT is then passed to the Authorization endpoint in an authorization request of Upstream to start the flow with the upstream provider (e.g. the bank), 3) the upstream flow is completed and redirects back to Ident, 4) the claims are then retrieved from the upstream identity provider and associated to the end-user that started the flow, 5) Upstream issues an OpenID ID token, which is then accepted as valid proof-of-identity by other services in our system. | |
| May 7, 2022 at 10:39 | comment | added | Cochise Ruhulessin | Indeed, the client credentials flow is fit for some idps. The concrete use case that sparked this question was the integration of iDIN with Upstream. IDin is a collaboration between Dutch banks were the end-user can identify itself using its internet banking portal. Because of compliance reasons we can not accept the username/password, and usually iDIN also requires approval using a security token (most commonly the internet banking mobile application). The flow is then as follows: | |
| May 7, 2022 at 10:36 | comment | added | Cochise Ruhulessin | to these systems. The Upstream system itself also implements OAuth 2.0 (and this is the system I referred to in the question). As the Upstream system does not maintain the user session (the Ident system does) we have to provide credentials of our user to it (during the authorization code flow) in order to correctly associate the claims from the upstream idp to our user. | |
| May 7, 2022 at 10:34 | comment | added | Cochise Ruhulessin | Hi Dan, thank you for your elaborate reply, it clarifies a lot for me. Regarding your concluding remark, our setup is as follows: - We have system that manages user registration, accounts, user ids etc ("Ident"), which issues a JWT identifying the end-user. - Another system ("Upstream") is used to obtain claims about the identity from other identity providers. Sometimes these idps implement OAuth 2.0 themselves, but in some cases they have flows similar to the authorization code flow, but not OAuth 2.0, or some end-user intervention is required. The Upstream system functions as a facade | |
| May 7, 2022 at 6:08 | history | edited | Dan | CC BY-SA 4.0 | added 463 characters in body |
| May 7, 2022 at 6:03 | history | answered | Dan | CC BY-SA 4.0 |