What is the difference between ID Token and Access Token
After verifying provided credentials, cidaas provides tokens. While Access Token is used to authorize access to a resource, ID Tokens are to be inspected to find information that can be used to verify and identify the user.
Access Tokens are tokens that grant access to a resource. Any request bearing a valid Access Token is granted permission by the application based on authorizations that are configured within.
However, an ID Token is meant to be inspected by the application to find out details like who issued it and to whom it was issued.
cidaas issues tokens that are OAuth2 and OpenID Connect compliant. The token is built up as a JWT (JSON Web Token), which is essentially a base64-encoded JSON format.
Optionally, during user authentication, cidaas can also provide an ID token, which is based on the OIDC standard and also built up as a JWT.
How to decode JWT tokens?
The Authkit.io - JWT Decoder allows you to decode JWT tokens. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. It is often used for Authorization and Information Exchange in Identity & Access Management.
In addition, you could have a look at the different flows in our OAuth playground.
Visit here authkit.io
Do you want to learn more about JWT? -> cidaas doc Validate Token
Let us have a more detailed view of the different token types
Access Token
proves that the client has been authorized
As mentioned above, cidaas provides the access token as a JWT token. The OAuth specification does not define how the token should look; it could also be a random string.
| ✅ good idea | ❌ bad idea |
|---|---|
| send it to a resource server | evaluate on client side |
| check information in token on server side | share it with others, other than known resource servers |
| check access rights of the specific app |
ID Token
proves that the user has been authenticated
The OIDC specification defines the ID Token as a JWT, so contrary to OAuth, you have to provide it as a JWT token and most of the claims are specified by the spec.
| ✅ good idea | ❌ bad idea |
|---|---|
| get data of the user | share it with others |
| accept the user is authenticated |
Refresh Token
Last but not least, there is another useful token type, named Refresh Token. A Refresh Token is a random string or UUID. The token itself doesn't provide any other information about what it is, where it comes from, where it can be used or any other information; it is just a simple "string" e.g. 550e8400-e29b-11d4-a716-446655440000
By sending a Refresh Token, bound with clientID and original redirect-uri, a client can get a new valid Access Token.
The perfect usage for Refresh tokens is mobile clients.
Let us explain this with an example:
In a mobile app, you may want to provide long sessions to avoid multiple logins during usage. However, due to security reasons, you cannot keep the same Access Token valid for a very long time.
This is when a Refresh Token can be used to request a new valid Access Token. For instance, an Access Token may be valid for 15 minutes and the Refresh Token could be valid for 30 days. If an attacker steals your Access Token, they will not be able to use it as it will expire quickly. Your mobile app can use the Refresh Token within the next 30 days to get a new Access Token. If someone gets access to the Refresh Token, they don't know what to do with it.
It is comparable to finding a key without any information; you don't know which door it matches; moreover, with a Refresh Token, one doesn't know that it is a key.
Need Support?
Please contact us directly on our support page