While interacting with Azure AD, applications receive ID tokens after authenticating the users. The applications use access tokens and refresh tokens while interacting with APIs.

All these tokens are Json Web Tokens (JWTs), hence all of them have header, payload and signature.

Let’s quickly try to have look at some basic information related to these three types of tokens.

ID Tokens

ID Tokens are sent back to application as a part of OIDC flow. These tokens contains claims that can be used to validate identity of the user.

The ID token is securely sent between the communicating parties. The claims in this token can be used as per requirements of your application.

After the user is authenticated using Microsoft Identity Platform, the ID token is sent back to the application, optionally with the access token.

After receiving this token, the token should be validated to make sure that the token was issued by valid issuer and it was not tampered with.

These tokens are signed, but they are not encrypted.

Access Tokens

This token is also a JWT. It contains claims which can be used to identify the granted permissions. Like id tokens, these tokens are also signed, but not encrypted.

Generally, access tokens are used to access APIs and resource servers. When an API receives an access token, it must validate its authenticity.

The signature should be validated. Also, other claims should also be validated based on need of your requirements.

Refresh Tokens

Refresh tokens are used to get new id tokens and access tokens.

Generally, the id tokens and access tokens are short lived. They are valid for short period of time (expire in minutes). The refresh tokens make sure that the application is able to access the resources for longer period of times (usually in hours).

The application should not assume that refresh token will be valid for any amount of time. The refresh tokens can be invalidated for many reasons.

Once the refresh token is used to get new id token or access token, a new refresh token is received. The application should take care of replacing the old refresh token with new one to make sure that the application can function for as much longer as possible.

It’s not safe to keep the refresh tokens active for very long duration. Generally policies should be configured to invalidate the refresh tokens in certain scenarios like maximum inactivity duration, etc.

I hope this article provides some basic information about what are these tokens and what their purposes are. Let me know your thoughts.