What are Access Token, Refresh Token and Id Token?

These tokens are used in the OAuth 2.0 authorization framework, which provides a secure and standard way for clients to access protected resources on the server. These tokens are used to authenticate users and authorize access to protected resources in your API or application.

Access Token

An access token is a JSON Web Token (JWT) issued by the service after successful authentication. It allows a client to access protected resources on the server. Access tokens typically have a short lifespan (e.g., one hour) and must be refreshed after they expire using a refresh token.

Refresh Token

A refresh token is a JWT issued by the service and an access token after successful authentication. It allows a client to obtain a new access token without requiring the user to re-authenticate. Refresh tokens typically have a longer lifespan (e.g., one week) and can be used to obtain multiple access tokens over time.

ID Token

An ID token is a JWT issued by the service after successful authentication. It contains information about the authenticated user, such as their username and attributes. ID tokens can be used to get user information or to implement additional security measures.

Where to store these tokens? 

There are several options for storing access, refresh, and ID tokens in your application. Here are a few common approaches:

Cookie storage

One option is to store the tokens in a secure cookie on the client. This allows the tokens to be persisted across multiple requests and can be convenient for single-page applications (SPAs) or other client-side applications. However, this approach requires the tokens to be sent with every request, which may only be suitable for some use cases.

Local storage

Another option is to store the tokens in the browser's local storage. This allows the tokens to be persisted across multiple requests. Still, they are only accessible from the same browser and device. This approach is suitable for SPAs or other client-side applications. Still, it may not be suitable for applications that support multiple devices or platforms.

Server-side storage

A third option is to store the tokens on the server, in a database or other persistent storage system. This allows the tokens to be shared across multiple clients and devices. Still, it requires the server to manage the storage and retrieval of the tokens. This approach is suitable for APIs or other server-side applications that need to support multiple clients or devices.

Which option you choose will depend on your application's needs and your use case's security requirements. It's essential to choose an appropriate secure storage mechanism that can meet your users' needs.

Where are to store Refresh Tokens?

It is generally not considered a good security practice to store refresh tokens in client-side storage, such as session or local storage. This is because refresh tokens are intended to have a longer lifespan than access tokens and can be used to obtain multiple access tokens over time. Suppose a refresh token is stored in client-side storage, and an attacker can access it. In that case, they could use it to obtain unauthorized access to the protected resources on the server.

It is generally recommended to store refresh tokens on the server, in a database, or in other persistent storage systems to improve security. This allows the refresh tokens to be managed and controlled by the server. It prevents them from being accessed by unauthorized clients.

Suppose you store refresh tokens on the client. In that case, it is vital to use a secure storage mechanism that is not easily accessible to attackers. One option is to use an HTTP-only cookie, which can only be accessed by the server and not by client-side JavaScript. This can help to prevent attackers from accessing the refresh token through cross-site scripting (XSS) attacks or other client-side vulnerabilities.

Where are to store Access Tokens?

It is generally recommended to store the access token in a secure storage mechanism that is easily accessible to the client-side code. This allows the access token to be used to make authenticated requests to the server and access protected resources.
One option for storing the access token is to use a library like react-cookie or js-cookie, which allows you to set and get cookies in a React application quickly. You can set a secure, HTTP-only cookie with the access token when the user logs in and then retrieve the cookie on subsequent requests to make authenticated requests to the server.

Another option is to use the localStorage or sessionStorage APIs to store the access token in the browser's local or session storage. This allows the access token to be persisted across multiple requests and can be convenient for single-page applications (SPAs) or other client-side applications. However, it is essential to be aware that the local storage and sessionStorage APIs are vulnerable to cross-site scripting (XSS) attacks, so it is essential to use them with caution and to sanitize any user input properly.

Where are to store ID Tokens?

It is not recommended to store Refresh Tokens or ID tokens in the front end of your application. These tokens contain sensitive information and may be used to grant additional privileges. Instead, storing these tokens on the server, in a database, or in another persistent storage system is generally recommended.