1. Introduction
We use tokens to authenticate users and authorize requests without keeping session data on the server. Tokens are data confirming a user’s identity and are analogous to digital signatures.
In this tutorial, we’ll clarify the distinction between access and refresh tokens and show how to implement them.
2. What Are Access and Refresh Tokens?
A careful balance between security and user experience is essential for authentication and authorization. A user may become irritated if protocols are overly strict. On the other hand, a security breach is imminent if permission systems are too loose.
Access and refresh tokens provide a solution that meets both requirements.
3. Access Tokens
An access token (from an authorization server) allows temporary access to restricted resources such as APIs or websites.
Generally, access tokens are valid for only a few minutes or hours, depending on the setting to safeguard the resource server. They also include security features like signatures.
Any user with an access token is automatically authenticated, regardless of whether they are genuine or malicious. Let’s check out an example:
In this case, the client application can access the user’s resource using an access token. The authorization server issues an access token following successful user authentication and consent.
The chance of the access token being compromised or stolen increases the longer it’s valid. While maintaining a positive user experience, pairing long-duration refresh tokens with short-duration access tokens improves security.
4. Refresh Tokens
In OAuth 2.0 authorization frameworks, refresh tokens allow developers to manage users’ sessions across native, web-based, and single-page apps.
Additionally, they allow users to log in and stay connected without providing their passwords for long periods. Further, they add a layer of security for sensitive data, improving the user experience.
Refresh tokens can last from a few days to a few months.
Refresh tokens by themselves don’t grant the user any access. To avoid needless re-authentication, they prolong the duration of the session.
4.1. Why Do We Need Refresh Tokens?
Let’s take an example of an access token that is only good for 8 minutes for accessing an application. What happens if we spend 16 minutes using the application?
From a security standpoint, the session should end after 8 minutes. There’s no benefit to a user who experiences this, and there’s a risk of low user satisfaction.
Using a refresh token in this situation would help to create a new set of access and refresh tokens after 8 minutes without asking users to re-enter their credentials.
Typically, we want to configure the refresh token’s lifetime to be much longer. Further, it’s possible for applications to get fresh access tokens during the refresh token’s lifetime without having to ask the user to re-authenticate.
4.2. Reuse and Reauthentication
When the authorization server notices a refresh token reuse, it instantly revokes the refresh token and prevents a user from accessing subsequent requests. Reauthentication is required since there is no way to tell if the refresh token is coming from a reliable source.
By identifying an invalid refresh token usage, whether by a genuine client or an attacker, the authorization server can discover a breach caused by a compromised refresh token. This is because the authorization server keeps the old refresh token after issuing a new one.
5. Prerequisites
To implement the tokens, we’ll require two models: one for users and the other for access and refresh tokens. User models contain data such as usernames, passwords, e-mail addresses, and other details.
On the other hand, a token model includes a refresh token’s value, expiration date, and user ID. We can store tokens in a cache or a secured relational database.
Additionally, we’ll need a set of secret keys, also known as public/private keys, for signing and authenticating tokens. Access and refresh tokens are issued only to users with valid usernames and passwords.
Refresh tokens are shared only between the authorization server and the granted client and must be private in transit using TLS.
6. How to Implement Access and Refresh Tokens?
Let’s now discuss how to set up the tokens:
Let’s say a client requests an access token by authenticating with the authorization server and delivering a credential that proves the resource owner is authorized to use the resource.
The authorization server verifies the authorization and confirms the identity of the authorized client. An access token and a refresh token are issued if it’s legitimate. The client must securely store this refresh token.
The client can now request the resource server for secured resource access like API, and the resource server validates the access token. If it’s valid, it returns the desired resource.
6.1. Invalid Access Token
When the application requests a resource, but the access token is no longer valid, then:
- the resource server should refuse to fulfill the request and sends an invalid token response
- the application will send a new access token request using the refresh token
- the authorization server will use the previously supplied refresh token and sends a new access token
7. Benefits and Drawbacks
Now, let’s discuss a few primary benefits of using access and refresh tokens.
8. Conclusion
In this article, we discussed the differences between access tokens and refresh tokens. They reduce the load on the server since there is no need to store or query session data for each request.
We can say a refresh token makes it possible to re-validate a user without requiring them to provide their login information repeatedly.
If the refresh token is legitimate and asks for authorization to access confidential resources, the access token is re-issued.
Further, when the authorization server notices a refresh token reuse, it instantly revokes the refresh token, and reauthentication is required.
Finally, refresh token rotation is a security precaution provided to reduce the dangers that come with compromised refresh tokens.