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

The Problem

Note: This article focuses on OAuth2 as described in rfc6749.

Hello everyone, recently I have been reading some discussions online about using access tokens (AT) and refresh tokens (RT) in a reasonable way. Some people say that implementing AT is enough, while others argue that RT is also necessary for security. In addition, there are questions about where to store AT and RT in the browser to ensure absolute safety.

Today, let's analyze each issue to see the truth behind it.

What are Access Tokens and Refresh Tokens?

First and foremost, for those who are not familiar, an AT is a string (usually a JWT) that is used to represent a user's actions in a system. For example, when you log in to a system, it will return an AT to you, and you store that AT for subsequent API calls.

If websites are built in a server-rendered style, we can also use session cookies to represent the user's session. However, nowadays, with the rise of client-rendered websites using frameworks like React, Angular, Vue, etc., the use of AT and RT is very common.

On the other hand, an RT is a code used to obtain a new AT. Let's clarify why we need to use RT.

What is Authorization?

First, let's understand what authorization is. Usually, when building a website, user registration and login features are quite common. When you log in, you have to enter a username and password to verify your identity. The system confirms the information you enter is correct and returns an AT, which represents you with certain privileges in that system.

In OAuth, the authorization process is triggered when you click on the sign-up/login button using accounts from Google, Facebook, etc. The system will redirect you to a screen where you need to approve granting access to some of your information, such as email, name, date of birth, etc. At that moment, Google or Facebook will return an AT. Based on that, the other system can retrieve your information to confirm your identity.

In summary, authorization is the process of confirming an identity to obtain an AT, which can be used on behalf of the user to use the system.

Therefore, having an AT is almost equivalent to having an account in a system. Leaking an AT is very dangerous because an attacker can impersonate you and interact with the system without your knowledge. That's why an AT needs to be stored as securely as possible, or if not, its validity period should be minimized. For example, an AT can only be valid for 5 minutes, and after that, the user is required to log in again! If you choose that approach, it can be a terrible user experience :D.

The Relationship between Access Tokens and JWT

One important thing to note is that an AT is usually a JWT (JSON Web Token). It is a standard for securely transmitting information between parties as a JSON object. This information is highly reliable because it is signed using secret keys and algorithms like HMAC, RSA, or ECDSA.

A JWT consists of three parts: the header, the payload, and the signature. The header contains basic information about the JWT, such as the signing algorithm and expiration time. The payload contains the actual data in the form of a base64-encoded JSON object. Lastly, the signature is a combination of the header and payload encrypted with the secret key and the specified algorithm.

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

Because the necessary information for transmission is contained in the payload, the system can identify the user's identity based on it.

For example, my payload might contain the following information:

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

When sent to the system, it can read my ID and determine who I am.

One extremely important note is that the information in the payload is only base64-encoded, which means that from a JWT, I can extract information from the payload. Therefore, you need to be cautious when putting information into the payload before signing it. Make sure that sensitive information such as passwords or unnecessary personal data is not included.

When a JWT is sent to the server, it can easily determine if the signature part is valid. Any modification to the payload will result in a change in the signature as well. Moreover, an attacker will never know the secret key used to sign the modified content.

Should We Use Refresh Tokens?

I wouldn't encourage everyone to implement RT or how to implement it. I know many systems that work well without implementing RT. Instead, I will point out some things to consider when using AT and RT.

There are a few reasons why AT should only exist for a short period of time, such as:

• An access token is an authorized code signed by the authorization server. The resource server only needs to receive the access token and verify it. Therefore, the shorter the expiration period of the access token, the less risk it poses when leaked.
• If the valid period of AT is too long, the risk increases when it is leaked because the attacker has more time to exploit it, and you may not even know that your AT has been leaked.
• Imagine if you allow users to generate too many ATs. In that case, if you want to invalidate the remaining ATs, you have to mark them in the database. In other words, you need to store the generated ATs.

There are also a few reasons why RT is used, such as:

• Shorten the existence time of AT. When AT expires, use RT to obtain a new AT.
• You need to differentiate between the authorization server and the resource server. The authorization server provides RTs and signs ATs to represent the user. The resource server receives the signed token from the authorization server to be able to have the user's privileges, such as accessing their account information, data, etc. The authorization server and the resource server can be the same. RTs are usually stored on the authorization server for the purpose of issuing new ATs. On the other hand, ATs are used on the resource server to identify a user.
• You don't need to store multiple ATs. If you want to terminate a session, you can simply disable the RT on the authorization server.

After understanding these reasons, we can see that introducing RT helps address some of the limitations when using only ATs. However, if an AT or RT is leaked, the risk will be high, right? And how should we store them? I will continue writing about it in the next section.

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