3 ms·
I don't understand the diagram. We have a browser sending a request to the identity provider. Then sometime later, the relying party is responding. How does
by recursive 3y ago
I don't understand the diagram. We have a browser sending a request to the identity provider. Then sometime later, the relying party is responding. How does the response come from a different server than the request went to?
Maybe it would help if each response was correlated to its corresponding request somehow.
- Arcanum-XIII 3y agoIt’s missing a step or two. Once you’ve selected your identifying provider, the user is redirected to it, identify itself and select there the claims he’s willing to share (most of the time only what’s needed for authorization). The identifying provider generate the proper token and claims, return them with the user to the third party site. Who can then authorize or not the identified user and return the user. This exchange of data and redirection is the core of the oauth.
- magicalhippo 3y agoThe app server requesting access has to be configured with the identity provider. Part of that is a redirect URL, which the identity provider redirects the client to once the authentication is ok. The URL is to an endpoint of the app server. When the id provider redirects, it includes the authorization code as an URL parameter or similar, so the app server can pick it up and call the id provider to exchange the authorization code for an access token. At least that's how I remeber it off the top of my head.
- mooreds 3y agoThanks for the feedback. I created the diagram and would love to improve it. I skipped a bit (as other folks have mentioned) and the 'authenticate the user' and 'obtain the user consent' steps both involve requests to the browser. I'll update the diagram to make it clearer.