Why do we need Refresh Tokens? Do you know how to securely store Refresh Tokens and Access Tokens in the browser?

The Issue

Note: This article discusses within the framework of OAuth 2.0 as described in rfc6749.

Hello, the story is that I have been following many people's discussions online these past few days about how to use access tokens and refresh tokens reasonably. After reading for a while, I realized there are two distinct schools of thought: some say that implementing only access tokens is sufficient, while others say that it is not secure without also having refresh tokens. However, the most prominent question is: assuming we have both access tokens and refresh tokens, where should we store them in the browser to ensure absolute safety?

So after many hours of reading through everyone's comments, I have gathered quite a bit of knowledge, including some things I used to do that were not very optimal. Therefore, let's sit down and find the answers together!

What are Access Tokens and Refresh Tokens?

Access tokens do not need much introduction; they are strings used to verify or represent a user in the system. A common example is when logging into a website, the system sends back a piece of code, which needs to be stored for subsequent API calls.

In the past, when PHP was prevalent, websites built with PHP were primarily rendered on the server side. What we often heard about back then was Session & Cookie. The server would return a value of the Cookie to determine a login session for the browser. When a query was sent, the Cookie accompanied it to help the server identify the user's session again. Nowadays, thanks to the development of various client-side rendering libraries like React, Vue, Svelte, etc., we are gradually shifting to a new session confirmation mechanism, which is the use of access tokens.

Therefore, fundamentally, an access token is just a piece of code returned by the server to identify a session for the client. Access tokens can be stored anywhere that can hold data, such as Cookies, LocalStorage, SessionStorage, or even in a file. But what about refresh tokens? What role do they play in the system? Simply put, refresh tokens are used to request a new access token.

Wait a minute, why do we need to issue a new access token? So it has an expiration time, right? Congratulations, you understand the issue correctly. But why complicate things like this? Isn't it enough just to use Sessions & Cookies as mentioned above? If you want to know the reason, let's first delve into the authorization problem.

The Authorization Problem

For many websites, the registration/login feature is indispensable as it is the best way to identify a user in the system. To log in, information such as email, phone number, along with a password is required. However, every day we use not just one website but possibly many, each requiring different login information, to the point where it becomes impossible to remember everything. It would be wonderful if you could log in everywhere with just one account. That’s when Google, Facebook, etc., come into play. Have you ever noticed the buttons with the label "Log in with Google"? You click it, the website redirects to Google, confirms the permission to access, and the login process is complete, so quick and risky, isn't it? Most of these login methods rely on the specifications of OAuth 2.

With OAuth 2, you can easily use another platform to log into a supported website, which is called authorization. It authorizes a website to read account information such as name, email address, phone number, etc., thereby identifying who you are and setting up a new usage session. Technically, after verifying identity, the server returns to the processing flow as if logging in with email and password normally, except that no information needs to be entered anymore, just a confirmation with the authorization provider.

Access tokens appear in the specifications of OAuth 2. An access token is returned immediately after authorization. That is, as soon as you click the button to allow access, the access token is returned to the website logging in. Based on that, the website verifies that you are a user in their system. Similarly, refresh tokens also appear in the specifications of OAuth 2. Access tokens usually have a very short lifespan (TTL), while refresh tokens are typically longer. When the access token expires, the refresh token is needed to request a new access token. This continues until the refresh token is invalidated, at which point no more can be requested.

Today, many websites build their login systems according to the specifications of OAuth 2 or at least something similar. Immediately after successful login, the system returns both refresh tokens and access tokens. The developers' job is to store these two important pieces of information in the browser for use in each subsequent call. They also have to handle expiration, renewal, invalidation, etc., of the access token.

Thus, having access tokens is almost tantamount to possessing an account in any system. The leakage of the access token is very dangerous because an attacker can impersonate a user and interact with the system without being detected. For this reason, access tokens must be stored or protected as securely as possible. So how can we best protect it? First, let's analyze what an access token consists of.

Access Tokens and JSON Web Tokens

Access tokens can be any string. However, most of them are usually JWT (Json Web Token). It is a standard for transmitting safe information between parties with data being a JSON object. This information is highly reliable because it has been signed using algorithms such as HMAC, RSA, or ECDSA.

A JWT object consists of three parts: header, payload, and signature. The header contains basic information about the JWT string, such as the algorithm used for signing, expiration, etc. The payload is a JSON object that has been base64 encoded. Finally, the signature is the encoded part of the header and payload combined with a secret key and the algorithm specified in the header.

To learn more about JWT, you can refer to Introduction to JSON Web Tokens.

The content in the payload may look like this:

{
  "id" : 1,
  "username": "hoaitx"
}

When the access token is sent, the server verifies its validity and begins reading the information in the payload. This way, it knows who the user currently using the system is.

One important note is that the information in the payload is usually only encoded with base64, which means that the information in the payload can be extracted from the JWT string. The payload should only contain information sufficient to identify the user; it should not contain sensitive information such as passwords or account numbers.

Why is a Refresh Token Necessary?

As mentioned, access tokens usually have a short lifespan (to reduce security risks if exposed). When the access token expires, instead of requiring the user to log in again, the application can use the refresh token to request a new access token automatically and securely, providing a smoother user experience.

Access tokens carry all the data within; the server does not need to maintain session state. When receiving the access token, the server only needs to check the signature and decode it to retrieve the information in the payload, without involving any database in the process. This is the stateless characteristic, which helps reduce memory load and server queries, making it easier to scale the application.

However, the strength is also the weakness of a stateless design system: it cannot be revoked or changed once issued. If an access token is leaked, an attacker can use it to access resources until it expires, and the server cannot intervene at that time. To mitigate this risk, access tokens are usually designed to exist only for a short time, ranging from a few minutes to a few hours.

But if access tokens are so short-lived, when they expire, users will have to log in repeatedly, leading to a very poor experience. This is exactly why refresh tokens are needed. The refresh token serves as a "renewal ticket" — allowing the application to request a new access token automatically, without requiring the user to log in again. Unlike access tokens, refresh tokens are often managed by the server (for example, stored in a database), so the server can proactively revoke or disable refresh tokens whenever necessary (for instance, when a user logs out or shows signs of being compromised).

After understanding the specifications of OAuth 2, the structure and function of access tokens, as well as the necessity of refresh tokens, we will continue to explore how to store them safely and securely!

Why do we need a Refresh Token? Do you know how to securely store Refresh Tokens and Access Tokens in the browser? Part 2.