Syed Kazim Raza
You made my day by writing this article…
Huge thanks to you…
Austin Kim
This was so clear. My life will never be the same…
Boshan Sun
Best vid explaining OAuth and OIDC!
Nico
Great article! Thank you.
张强
Thanks very much for this awsome post!
But I have a question. OIDC is for authentication and get a ‘ID TOKEN’, so why not only use a access token to get the user’s information by using OAuth2.0 ?
Brian Demers
You could but how you would do that may be different between vendors. For example, GitHub supports OAuth 2.0 but IIRC, it doesn’t support “token introspection” (a different spec), so you would need to use GitHub specific APIs to get user information.
OAuth 2.0 Token Introspection (rfc 7662)
In OAuth 2.0 [RFC6749], the contents of tokens are opaque to clients.
This means that the client does not need to know anything about the
content or structure of the token itself, if there is any.
张强
Thank you very much.
awesome overview, thank you!
I have a dumbo question: with the Auth2 only (no OIDC overlay) token passed from the authorisatoin server to the client, presumably that exchange still contains identity at some level (that these permissions to retrieve my address book pertain to me, and the content returned is about me) … the OIDC overlay just adds additional features, such as session awareness, as well as further identity attributes?
presumably that exchange still contains identity at some level
No. The OAuth spec says that access tokens can be any random string of characters. They don’t even have to be a JWT. Therefore, there’s no identity information that should be contained in them. OIDC adds identity so you 1) get an ID token returned when you exchange the authorization code for an access token and 2) can call /userinfo with an access token and get additional information about the user.
This was great; very helpful.
I think this:
Redirect URI : The URL the Authorization Server will redirect the Resource Owner back to after granting permission to the Client . This is sometimes referred to as the “Callback URL.”
would be clearer if it was this:
Redirect URI : The Client URL the Authorization Server will redirect the Resource Owner’s browser back to after granting permission to the Client . This is sometimes referred to as the “Callback URL.”
Congratulations on the excellent content and the didactic way of explaining. Based on the Oauth2 flow, image 6 indicates an exchange using authorization_code, client_id and client_secret, but this leaves me confused because to send a client_secret the client application should know my secret I would be breaking security because this way if there is one (MITM man- in-the-middle) and get this client_secret will be able to request tokens on my behalf ???
The client secret is the application’s secret, and the request is made over TLS which prevents MITM attacks. If you are building a “public client” (SPA, mobile app, etc), then you would not be able to safely store and use a secret, so the secret is left out in that case, but everything else remains the same.