I was dumbly sweating off for 2 days trying to get user information from an "access token" but then I saw this video. The clear difference you explained makes so much sense. Thank you for developing this content, auth0.
You have made it to the point! This is an amazingly easly understandable content in the bushes of misinformation on the internet on that subject! You are explaing here much more than just a difference between the tokens! Well done!
The only confusing part was 6:33 where you say ID tokens should NOT be sent to an API. But yes, you DO send ID tokens to APIs as `Authorization: Bearer `.
I have a dumb question. If an access token provides authorization but not authentication, how in the example does Twitter know what user they are posting as? Seems that there MUST be at least an implicit authentication here?
@@goncaloazevedo9822 So they have a separate endpoint per user? (I don't think this is the case, but maybe.) Or are they abusing the "standard" and recording auth assignments for an access token?
OpenID Connect is the standard that provides authentication, but it also uses OAuth for authorization. So, both are used with many web-based aplications.
Great explanation on the difference between access and id tokens. I have a question about access tokens in Auth0 (since as of now there is no agreed upon specification) How does the api receiving the access token know who the requester is (username/email)? The access token proves the user is authorized to request a resource, but has no information who the user is. So how could a remote api determine someones identity information without using the identity token?
Attempting to answer my own question after some research: "The access token is not intended to carry the user data (except for ID passed as the sub claim)" So the remote api can use the "sub" field in the access token to query user data from auth0 such as email.
I don't know about Facebook or Google. However, in my org, we are using access token to get the clientId, scope and user info as well. Its called 3LO token.
If you send an access_token to the API how the API knows that it is allowed to do something on behalf of Jone Doe? There is nothing related to John Doe in the token itself
Great explanation! However, I have a query here. In an enterprise app, the user is authenticated at the frontend app (built in react, angular, etc.) and have the access to ID token, which would be user for future authentication. Now the frontend app needs to access protected RESTful API endpoint. So, authorization will be implemented using the same Identity server (which will act as Authorization Server)? So, for an enterprise app, authentication and authorization can be done using same Identity Server?
Assuming that the Identity provider (IdP) uses OpenID Connect, the answer is yes. OpenID Connect is built on top of OAuth 2.0, so the same server is both an Identity provider and an authorization server. Your frontend app can request both an ID token and an access token
If id token is for bring user info in payload, why does it need to be JWT? What situation I would validate signature if it came from a redirect from IdP?
If the access token shouldn’t be sent to my API from my front end, how can my backend know that the user is logged in? Sure, the frontend knows but if it can’t ever convey that information to the backend when making requests, what is it good for? I’m probably missing something obvious but I’m honestly confused.
I assume you mean the ID token, not the access token. Your ID token should not be used to tell your backend that the user is logged in (i.e., to create sessions). It's just a confirmation to your frontend app from the authorization server that the user has been authenticated. Your application is responsible for creating its own session using the appropriate technique. For example, in a Web application, you can rely on traditional cookies to create sessions. In a mobile application, you can use session tokens. ID tokens don't replace the way you create and manage your own sessions I hope this clarifies
@@andrea.chiarelli-okta thank you for your reply. Yes I did mean the ID Token. I think I probably need to read up more on this. I fail to see the benefit an ID Token offer except displaying email, name, etc. in the frontend if I can’t send it to my backend. Is this understanding correct? I currently store the ID token in memory only and not in local storage or cookie (Web App). I do send it to my backend. Is this completely wrong?
Thanks for the awesome video!, but I have a question, what if the APIs are like a BFF (APIs that are tied specifically to your web/app)?, in that case can be "good" to use the ID token as a Bearer?. If we need to just sent the access token, how can we use custom attributes (or validate custom permissions) if the information is not available in the token itself without continuously fetching and validating the data?. Thanks!
Could you please clarify you said that id token is only for authentication and not for authorization so does that mean if I am subscribed to a news site then that information is stored in access token but if on the other hand I only have an account with news site but have not purchased any subscription then that means the user information is in id token. Reason to ask that is because the news site is the same and there is no separate server where the news data is stored . Therefore the access to news site can only be defined in access token and not id token
If ID tokens(JWT) should never be sent to an API, then how the hell a client can be authenticated ? Why Spring Boot has inbuilt methods and structure for signing and validating JWT if we are not going to sent JWTs to Spring Boot API ? Am I wrong or everywhere I read (Stackoverflow, tutorials , etc..) it said exactly the opposite of your statement ?
The tokens that Spring Boot validates are access tokens, not ID tokens. If you try to send an ID token to a Spring Boot backend, it won't work. Spring Boot also supports validating opaque access tokens (that are not JWTs) via the introspection endpoint.
What is Identify provider? When we initially login / authenticate (a user) , is it against the Identify provider? Does identify provider provide the ID Token?
The identity provider is the one that provides the authorization server. For example, Google is an identity provider, as is Okta and Auth0. When you initially authenticate, you do that with the authorization server and it provides the ID token.
i am very confused the role of id_token, after the application request to authentication server, the server will return id_token, access_token。in my opinion, application request the backend api will pass id_token to backend sever, and backend will use id_token to judge the user is logged? but according the video, id_token is not passed to api. so id_token returned only tell the application the user is logged a moment? id_token will no any effect when api calling？
So if I create a token which a user can use to access resources using API calls in my application after he/she registers/logs-in herself, would that be an id token or an access token or a combination of both?
If you are using OpenID Connect to authenticate your users, you must use an access token to call the API. If you are not using OpenID Connect or OAuth, and you are creating your own token, the meaning and the purpose of the token is up to you. Hope that helps!
Awesome. Thumbs up of course. I am just curious if there is a tool that I can use to decode an ID token in code, preferably a command line utility like jq but for ID tokens?
We'd recommend checking out github.com/jwt-rs/jwt-ui You can encode and decode JWT ID tokens and access tokens using JWT UI on the CLI. Hope that helps!
No. The only time you can enrich an access token is upon login. However, you can add an API with a token lifetime of 30 seconds. Then, pass in `offline_access` as a scope, and you should get a new access token (with updates from actions, and therefore enriched) every 30 seconds. This depends on your SDK. It works with the Okta Spring Boot starter.
Hello, how are you, there are applications that request a token, request that the client id and seceret key be sent, others an api token and a secret key, how is this different from, for example, sending user and pass?
Client IDs and secret keys or API keys and secret keys are credentials for an application, that is, they identify the application, not the user. You can think of them as usernames and passwords, but just for the applications. An ID token simply tells an application that the user has been authenticated. An access token allows an application to access a resource on behalf of a user without using the user's username and password. So, both ID tokens and access tokens don't identify an application, while client IDs/API keys + secret keys do.
@@andrea.chiarelli-okta Thanks for all! for example when I have 2 internal applications that connect through an api or an internal application with an external one but I always use the same user to authenticate, would I use client and secret to be able to generate and use the token?
Just because an access token doesn't guarantee that a user is logged in does not, at all, seem to mean that we can't presume the user is authentic. They certainly did make authenticity clear in granting the resource access, so it does absolutely seem to be an authentication token. The only things that make it an authorization token, is if scopes are stored (and checked) associated with that token on the resource server. However, it's certainly also a claim of authenticity if it contains authentic claims for authorization. 😑🤨🤔
Thank you James! I have some questions What is the use case to have a decentralized authentication or is it preferable ? And for the OAuth protocol I think the use case for the apps that allows integrations and exposes the API to the public ? Or the use case can be suitable for a single app that have micro-services, and multiple clients like web, mobile apps ?
Thanks for the video, is it possible to get the access token when the scope is set to openid? If yes, flow used in OAuth2.0 can be followed in Openid as well?
"ID Tokens should NOT be sent to an API" is still confusing for me. I guess in most cases you want a single sign on in your web application, so you do not have to deal with the user managemnet yourself. Now probably your web application consists of a frontend (let's say a SPA) and one (or more) backend. In this case, are the frontend and the backend different clients, with different client ids? Now, in the backend of my web app, I need to identify the user because it is my backend which has to do the authorization (in most of the cases checking the userid (sub) against an access control list). But apprently I can not use the id token for that purpose? Looking at a how-to from google-developes this seems to be the way to go: ruclips.net/video/j_31hJtWjlw/видео.html ... What is your preferred way of identifying an user in the backend? Using the backend's client_secret to introspect the id token, or use the access token to call the userinfo endpoint of the ID provider?
There are two techniques I recommend for solving this problem: 1) add additional claims with identity information to your access tokens or 2) call the /userinfo endpoint on the backend with the access token to get identity info. If you do #2, you'll probably want to cache lookups for scalability.
I love this video. Very well made, the music and the animations are a great match. I think I know a few people that have or are using access tokens as a form of ID. This is a nuance that I only became aware after watching this video, so I definitely learned something new here. Thanks for making this video!
I miss the dislike counts being visible, RUclips fucked users and creators. I’m sure this video has so little dislikes, a shame not to display the winning ratio
The continued conflation of Authentication and Authorization is perpetuated by people using the horrible abbreviation "auth." For example, "OAuth" or "Auth0."
![Understanding the concepts of access control [The Confused Developer]](http://i.ytimg.com/vi/vULfBEn8N7E/mqdefault.jpg)
I was dumbly sweating off for 2 days trying to get user information from an "access token" but then I saw this video. The clear difference you explained makes so much sense. Thank you for developing this content, auth0.
Don't feel bad; big companies actually did their "custom hacking" of these before OpenID Connect to make them "fit into" this role as well.
Finally a clear and easy to understand video about the differences between these tokens but also OAuth2 and OIDC!
You have made it to the point! This is an amazingly easly understandable content in the bushes of misinformation on the internet on that subject! You are explaing here much more than just a difference between the tokens! Well done!
@OktaDev 1:42 "JAWT" is a shortened form of "JAson Web Token"
"JAWT" and "JOT" are only spoken. It's just the way some people pronounce "JWT" because "jay-double-you-tea" is pretty long.
The only confusing part was 6:33 where you say ID tokens should NOT be sent to an API. But yes, you DO send ID tokens to APIs as `Authorization: Bearer `.
I have a dumb question. If an access token provides authorization but not authentication, how in the example does Twitter know what user they are posting as? Seems that there MUST be at least an implicit authentication here?
Bro that is the thing I don't get as well... found an answer that makes sense and you want to share?
You can be granted access to a resource which is post as user. OIDC is just an extension of OAuth2.0 either way
@@goncaloazevedo9822 So they have a separate endpoint per user? (I don't think this is the case, but maybe.) Or are they abusing the "standard" and recording auth assignments for an access token?
I think the explanation is: the access token grants access to write USING THAT USER
I guess it is kinda like an “implicit authentication” as you said
OpenID Connect is the standard that provides authentication, but it also uses OAuth for authorization. So, both are used with many web-based aplications.
Great video! I especially enjoyed the illustrations created!
Thanks James. Great content as usual. I am a big fan.
Glad you enjoy it!
Can we send Id token to backend for getting the user's data?
Note: Sending acces token for api authorisation as well
Great explanation on the difference between access and id tokens.
I have a question about access tokens in Auth0 (since as of now there is no agreed upon specification)
How does the api receiving the access token know who the requester is (username/email)? The access token proves the user is authorized to request a resource, but has no information who the user is. So how could a remote api determine someones identity information without using the identity token?
Attempting to answer my own question after some research:
"The access token is not intended to carry the user data (except for ID passed as the sub claim)"
So the remote api can use the "sub" field in the access token to query user data from auth0 such as email.
@@Daniel-zl7wf Thanks bro. Very Informative 🙌
I've had the same question.
@@randomhandle307 What I've ended up using the sub field id within my own database as a userId. Not sure if this is the best way.
I don't know about Facebook or Google. However, in my org, we are using access token to get the clientId, scope and user info as well. Its called 3LO token.
If you send an access_token to the API how the API knows that it is allowed to do something on behalf of Jone Doe? There is nothing related to John Doe in the token itself
Please try on behalf flow
Thanks for the video. I feel like often people will use ID token and access token interchangeably. That causes a great deal of confusion.
Great explanation! However, I have a query here. In an enterprise app, the user is authenticated at the frontend app (built in react, angular, etc.) and have the access to ID token, which would be user for future authentication. Now the frontend app needs to access protected RESTful API endpoint. So, authorization will be implemented using the same Identity server (which will act as Authorization Server)? So, for an enterprise app, authentication and authorization can be done using same Identity Server?
Assuming that the Identity provider (IdP) uses OpenID Connect, the answer is yes. OpenID Connect is built on top of OAuth 2.0, so the same server is both an Identity provider and an authorization server. Your frontend app can request both an ID token and an access token
@@andrea.chiarelli-okta So, what if OIDC is not used for authentication? Some other protocol/framework being used?
@@matthayden1979 SAML is another protocol. It relies on exchanging XML documents (SAML Assertions) instead of tokens
This video is a gem. Thank you so much! 💎
If id token is for bring user info in payload, why does it need to be JWT? What situation I would validate signature if it came from a redirect from IdP?
wow that was a super delicious explanation!! Loved it!!
If the access token shouldn’t be sent to my API from my front end, how can my backend know that the user is logged in? Sure, the frontend knows but if it can’t ever convey that information to the backend when making requests, what is it good for?
I’m probably missing something obvious but I’m honestly confused.
I assume you mean the ID token, not the access token.
Your ID token should not be used to tell your backend that the user is logged in (i.e., to create sessions). It's just a confirmation to your frontend app from the authorization server that the user has been authenticated.
Your application is responsible for creating its own session using the appropriate technique.
For example, in a Web application, you can rely on traditional cookies to create sessions.
In a mobile application, you can use session tokens.
ID tokens don't replace the way you create and manage your own sessions
I hope this clarifies
@@andrea.chiarelli-okta thank you for your reply. Yes I did mean the ID Token.
I think I probably need to read up more on this. I fail to see the benefit an ID Token offer except displaying email, name, etc. in the frontend if I can’t send it to my backend. Is this understanding correct?
I currently store the ID token in memory only and not in local storage or cookie (Web App). I do send it to my backend. Is this completely wrong?
Thanks for your reply, Andrea! :)
Thanks for the awesome video!, but I have a question, what if the APIs are like a BFF (APIs that are tied specifically to your web/app)?, in that case can be "good" to use the ID token as a Bearer?.
If we need to just sent the access token, how can we use custom attributes (or validate custom permissions) if the information is not available in the token itself without continuously fetching and validating the data?.
Thanks!
@Alejandrombc did you get an response ? We are in same boat
the differences were explained very nicely!
You are simply great with your knowledge and explanation😊
Great video. Very clear. Thank you!
Super informative and concise. Excellent! MM
Could you please clarify you said that id token is only for authentication and not for authorization so does that mean if I am subscribed to a news site then that information is stored in access token but if on the other hand I only have an account with news site but have not purchased any subscription then that means the user information is in id token. Reason to ask that is because the news site is the same and there is no separate server where the news data is stored . Therefore the access to news site can only be defined in access token and not id token
how do we do authorization then ? the accessToken is not in jwt format, it's in jwe or something.
Very helpfull & info page Thanks
If ID tokens(JWT) should never be sent to an API, then how the hell a client can be authenticated ? Why Spring Boot has inbuilt methods and structure for signing and validating JWT if we are not going to sent JWTs to Spring Boot API ? Am I wrong or everywhere I read (Stackoverflow, tutorials , etc..) it said exactly the opposite of your statement ?
The tokens that Spring Boot validates are access tokens, not ID tokens. If you try to send an ID token to a Spring Boot backend, it won't work. Spring Boot also supports validating opaque access tokens (that are not JWTs) via the introspection endpoint.
What is Identify provider? When we initially login / authenticate (a user) , is it against the Identify provider? Does identify provider provide the ID Token?
The identity provider is the one that provides the authorization server. For example, Google is an identity provider, as is Okta and Auth0. When you initially authenticate, you do that with the authorization server and it provides the ID token.
crystal clear, thanks a ton :)
Well explained. Thank you
i am very confused the role of id_token, after the application request to authentication server, the server will return id_token, access_token。in my opinion, application request the backend api will pass id_token to backend sever, and backend will use id_token to judge the user is logged? but according the video, id_token is not passed to api. so id_token returned only tell the application the user is logged a moment? id_token will no any effect when api calling？
Fantastic video. Very thorough and at the same time concise.
Great to hear, thanks for the feedback!
Nice explanation 🙂 Thanks for the video 🙂
That was very nicely explained. Thank you!
So if I create a token which a user can use to access resources using API calls in my application after he/she registers/logs-in herself, would that be an id token or an access token or a combination of both?
If you are using OpenID Connect to authenticate your users, you must use an access token to call the API.
If you are not using OpenID Connect or OAuth, and you are creating your own token, the meaning and the purpose of the token is up to you. Hope that helps!
Awesome content!! Thanks a lot 🙌🏾❤
Awesome. Thumbs up of course. I am just curious if there is a tool that I can use to decode an ID token in code, preferably a command line utility like jq but for ID tokens?
We'd recommend checking out github.com/jwt-rs/jwt-ui
You can encode and decode JWT ID tokens and access tokens using JWT UI on the CLI. Hope that helps!
Thanks for a simple and clear explaination
Nice one 🎉 informative and helpful 👍
Nice, One question - Can we add new claim to access token after logged in?
No. The only time you can enrich an access token is upon login. However, you can add an API with a token lifetime of 30 seconds. Then, pass in `offline_access` as a scope, and you should get a new access token (with updates from actions, and therefore enriched) every 30 seconds. This depends on your SDK. It works with the Okta Spring Boot starter.
Nice video. Appreciated. Can we use both in the payment gateway integration
Great explanation, thank you
You are welcome! James is great at explaining things!
Great video!! Thanks.
Hello, how are you, there are applications that request a token, request that the client id and seceret key be sent, others an api token and a secret key, how is this different from, for example, sending user and pass?
Client IDs and secret keys or API keys and secret keys are credentials for an application, that is, they identify the application, not the user. You can think of them as usernames and passwords, but just for the applications.
An ID token simply tells an application that the user has been authenticated.
An access token allows an application to access a resource on behalf of a user without using the user's username and password.
So, both ID tokens and access tokens don't identify an application, while client IDs/API keys + secret keys do.
@@andrea.chiarelli-okta Thanks for all! for example when I have 2 internal applications that connect through an api or an internal application with an external one but I always use the same user to authenticate, would I use client and secret to be able to generate and use the token?
Just because an access token doesn't guarantee that a user is logged in does not, at all, seem to mean that we can't presume the user is authentic. They certainly did make authenticity clear in granting the resource access, so it does absolutely seem to be an authentication token. The only things that make it an authorization token, is if scopes are stored (and checked) associated with that token on the resource server. However, it's certainly also a claim of authenticity if it contains authentic claims for authorization. 😑🤨🤔
Nicely presented, thank you
Thanks James! You rock.
Great explaination. Saved
Ok so what token can be sent to API if not ID token and auth token?
It should be an access token. When you use authorization code flow with OpenID Connect, you'll get both an ID token and access token.
Great video compact and informative
In simple, id token identifies user, and access token gives access to protected resources
Thank you James! I have some questions
What is the use case to have a decentralized authentication or is it preferable ?
And for the OAuth protocol I think the use case for the apps that allows integrations and exposes the API to the public ? Or the use case can be suitable for a single app that have micro-services, and multiple clients like web, mobile apps ?
JWT is for Authorization
Great video.
well explained - thx!
thanks for watching!
You are just awesome ❤
Awesome, Thank you so much boss
Thank you.
You got it!
Thanks for the video, is it possible to get the access token when the scope is set to openid?
If yes, flow used in OAuth2.0 can be followed in Openid as well?
Thank you
JWT sounds like "Jawt". I call them JWT "jawt" tokens because that is what I see when I see the three letters.
"ID Tokens should NOT be sent to an API" is still confusing for me. I guess in most cases you want a single sign on in your web application, so you do not have to deal with the user managemnet yourself. Now probably your web application consists of a frontend (let's say a SPA) and one (or more) backend. In this case, are the frontend and the backend different clients, with different client ids? Now, in the backend of my web app, I need to identify the user because it is my backend which has to do the authorization (in most of the cases checking the userid (sub) against an access control list). But apprently I can not use the id token for that purpose? Looking at a how-to from google-developes this seems to be the way to go: ruclips.net/video/j_31hJtWjlw/видео.html ... What is your preferred way of identifying an user in the backend? Using the backend's client_secret to introspect the id token, or use the access token to call the userinfo endpoint of the ID provider?
There are two techniques I recommend for solving this problem: 1) add additional claims with identity information to your access tokens or 2) call the /userinfo endpoint on the backend with the access token to get identity info. If you do #2, you'll probably want to cache lookups for scalability.
I love you, man
Awesome video
I love this video. Very well made, the music and the animations are a great match. I think I know a few people that have or are using access tokens as a form of ID. This is a nuance that I only became aware after watching this video, so I definitely learned something new here. Thanks for making this video!
thanks man
"...maybe not that stressful..."
Sir, it definitely is. xD
Can somebody explain to me about accesstoken more clearly???? 😅
Check out this video! ruclips.net/video/BNEoKexlmA4/видео.html
I miss the dislike counts being visible, RUclips fucked users and creators. I’m sure this video has so little dislikes, a shame not to display the winning ratio
❤
Finally I understand ID token and Access token. Thank you so much sir!
TL;DR - ID tokens are for id. Access tokens are for access. So confusing.
The continued conflation of Authentication and Authorization is perpetuated by people using the horrible abbreviation "auth." For example, "OAuth" or "Auth0."
Brown George Lewis Nancy Davis Betty
recap: ID token is the token return from JWT, Access token is the token return from Oauth2