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.
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 `.
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!
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 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?
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
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!
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?
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
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?
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!
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.
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. 😑🤨🤔
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 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？
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 ?
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.
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.
"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: ua-cam.com/video/j_31hJtWjlw/v-deo.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.
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?
I miss the dislike counts being visible, UA-cam 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."
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.
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 `.
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.
Finally a clear and easy to understand video about the differences between these tokens but also OAuth2 and OIDC!
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!
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.
Thanks James. Great content as usual. I am a big fan.
Glad you enjoy it!
Thanks for the video. I feel like often people will use ID token and access token interchangeably. That causes a great deal of confusion.
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! :)
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
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
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
Can we send Id token to backend for getting the user's data?
Note: Sending acces token for api authorisation as well
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?
the differences were explained very nicely!
You are simply great with your knowledge and explanation😊
wow that was a super delicious explanation!! Loved it!!
how do we do authorization then ? the accessToken is not in jwt format, it's in jwe or something.
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
This video is a gem. Thank you so much! 💎
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?
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!
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.
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. 😑🤨🤔
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 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？
Nice explanation 🙂 Thanks for the video 🙂
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 ?
Fantastic video. Very thorough and at the same time concise.
Great to hear, thanks for the feedback!
Super informative and concise. Excellent! MM
Great video. Very clear. Thank you!
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.
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!
Nice video. Appreciated. Can we use both in the payment gateway integration
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.
In simple, id token identifies user, and access token gives access to protected resources
Awesome content!! Thanks a lot 🙌🏾❤
Thanks for a simple and clear explaination
That was very nicely explained. Thank you!
Nice one 🎉 informative and helpful 👍
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.
Great explanation, thank you
You are welcome! James is great at explaining things!
Well explained. Thank you
JWT is for Authorization
Nicely presented, thank you
Great video compact and informative
crystal clear, thanks a ton :)
"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: ua-cam.com/video/j_31hJtWjlw/v-deo.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.
Great explaination. Saved
JWT sounds like "Jawt". I call them JWT "jawt" tokens because that is what I see when I see the three letters.
Thanks James! You rock.
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?
Great video!! Thanks.
Awesome, Thank you so much boss
Thank you
Great video.
You are just awesome ❤
Thank you.
You got it!
Finally I understand ID token and Access token. Thank you so much sir!
well explained - thx!
thanks for watching!
"...maybe not that stressful..."
Sir, it definitely is. xD
Can somebody explain to me about accesstoken more clearly???? 😅
Check out this video! ua-cam.com/video/BNEoKexlmA4/v-deo.html
Awesome video
thanks man
recap: ID token is the token return from JWT, Access token is the token return from Oauth2
I miss the dislike counts being visible, UA-cam fucked users and creators. I’m sure this video has so little dislikes, a shame not to display the winning ratio
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."
I love you, man
❤
Brown George Lewis Nancy Davis Betty