 ID token, access token, ID token, access token. What's the difference? All right, maybe the difference between ID tokens and access tokens is not quite that dramatic and stressful, but you probably do have questions. Maybe you've worked on applications where you're building authentication or incorporating authentication with a third-party platform, and you've heard these terms, ID tokens, and access tokens, and you're not exactly sure what they are, and most importantly, how they are to be used, and most more importantly, how they're not to be used. So let's talk about all that in this video today. There's also a cheat sheet that will break down the difference between ID tokens and access tokens to recap all the things that we say in the associated blog post. You can find that and download it for free with the link in the description below to the blog post. That said, let's go ahead and dive into the difference between ID tokens and access tokens. All right, for ID tokens, let's start by talking about OpenID Connect. OpenID Connect is an open standard for decentralized authentication, and the good thing is this is used by many or all of the most popular identity providers out there, things like Google and Facebook and Twitter. So this is basically a workflow for a user to authenticate themselves and the output of this, what OpenID Connect provides as an output artifact is an ID token that proves the user has been authenticated. Now for ID tokens, these are specifically encoded as a JWT or JSON web token, also referred to as JOTS, although I still don't quite get that. So I'm going to use JWT in here to refer to JSON web tokens. So ID tokens are required to be in the format of a JWT, and JWTs typically consist of three parts. They've got the header, the payload, or the body, and then the signature. For reference, if you ever have a JSON web token and you want to see the information that's inside of it, you can head on over to JWTIO to decode that information and see all the stuff that's right there. Now inside of the payload or the body with the JSON web token, you'll have several different claims or pieces of information. You might have a sub property, which is the unique identifier for a user. You might have an audience, which is basically who the intended receiver is to use this ID token. This will be important. We'll come back to this in a second. You might have the issuer, the identity provider who created the token, and you might have the name or other pieces of information about the user themselves. Now I mentioned this audience property would become important with ID tokens and here in a second with access tokens. So the audience property is defining which application is meant to be the final recipient of an ID token. In most cases, that's gonna be like a client application because we might do things like this. Inside of an application, you log in, you then get redirected back to your application and after you've completed the login in the top right corner, you might see your username and your profile image or something like that with a dropdown button and it's got logout and settings and dashboard and things like that. So that ID token is being used to grab that information about the user like their name and their profile image. So who is the intended final recipient of this ID token? Well, it's the application that the user is currently logged into and that ID token can be used to display their information on the app. Now, let's transition over to access tokens. Access tokens are specifically designed to allow you access to a resource. A resource could be a file, it could be a database or most likely it could be an API that you can call to do CRUD operations on some sort of data. Now, where do access tokens come from? ID tokens came from OpenID Connect. Access tokens in this case come from OAuth2. OAuth2 is designed to allow an application to access specific resources on behalf of a user. So let's talk about an example here. Let's say you log into your LinkedIn app and you start to post on LinkedIn frequently and you realize, hey, I might as well cross-post these things to Twitter so that I get that much more exposure for the content that I'm creating. Well, maybe LinkedIn could add some sort of ability to do that for you. So the way this would work is LinkedIn would redirect you over to Twitter. You would authenticate against Twitter and in addition to regular authentication, you will also grant access to certain scopes or things that the original application, LinkedIn, can do on your behalf with the resource server, which in this case is Twitter. The resources are reading your tweets, posting to your timeline, things like that. So you'll have to grant access to those certain scopes and embedded in that response is the access token that has the authorization to do those very specific things. Now, unlike ID tokens, access tokens don't have a specific required format. They can basically be in any string format, but you will often see them in the format of JWT's JSON web tokens the same way you will for ID tokens, although it's not a requirement. Now, one thing to note is there's currently a specification being worked on and formalized now that will define how to structure your access tokens as JSON web tokens, but we're not quite there yet. So in this case, access tokens can basically be any format of string. Oftentimes you will see them in the format of JSON web tokens, and that's what we use at all zero when you're making calls to a specific API. So let's go back to this idea of audience or who is the intended receiver of a token. For the ID token, we said it was the application that the user is logged into and we use that to display information about the user on the page and do a few other things. Access tokens are a little bit different. Access tokens are meant to be sent to a resource server to access some sort of API or data or something like that, which means if I'm inside of LinkedIn and I do that redirect over to Twitter, let the user log in and grant access to those scopes and redirect the user back to LinkedIn and then want to make a call to Twitter, Twitter as the resource server is the final intended recipient of this access token. So that is where that access token is supposed to be used. All right, so let's take a little bit of time to recap this first by starting with what these different types of tokens are not intended for. ID tokens are not meant for authorization. They are strictly for verifying that a user has logged in or authenticated themselves, which means they should not be sent to an API. Remember the audience claim, that audience claim is the application that the user is logged into, not a separate API that we will send a token to. So we do not send ID tokens to separate APIs. ID tokens also do not have any authorization information included inside of them. So they would basically be useless to send to an API anyway. So we don't send ID tokens to APIs and we don't use them for any sort of authorization. On the flip side, access tokens are not used for authentication. The interesting thing about this is that based on an access token, you can't actually make any assumption about the user's identity or the fact that they're logged in or not. Think about it, if you log into an application, if I logged in to LinkedIn, I go to Twitter, I do the redirect, I get the access token and then I log out of Twitter, that access token is still valid and still can be used. So the access token itself doesn't actually guarantee me that a user is logged in at all. So let's do the whole recap here. ID tokens are required to be in the format of a JWT or a JSON web token. They are the output of a workflow called OpenID Connect and they are strictly for authentication. Access tokens, on the other hand, do not have a required format, although there is a specification in the works for formatting them as JWTs, JSON web tokens. But access tokens are specifically used for delegated authorization and access, not for authentication. So oftentimes you'll see that these access tokens are sent to an API of some sort and embedded in that token is some sort of information that expresses its ability to do certain things. If you're looking for a quick recap of this and a really nice cheat sheet, again, you can get that for free in the link below in the associated blog post with this video. We hope you enjoyed it. If you have any other questions, let us know in the comments below. Thanks for watching and we'll catch you next time.