Hacker News Reader

Comment by recursive | Hacker News Reader

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.

View on HN

It’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.

The 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.

Thanks 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.

Diagram updated. Hope it is more clear now.

Thank you. This makes sense to me now.

Reply on news.ycombinator.com