Refresh Tokens Explained
Learn what a refresh token is, why they are needed, where to store them, and how refresh tokens are different from access tokens.
Table of Contents 📖
What is a Refresh Token?
When a user logs in with their credentials to a website that uses token authorization, they will most likely receive two tokens: an access token and a refresh token. The access token is used to identify and authorize the user in subsequent requests. The refresh token is used to obtain a new access token when the access token expires.
Why do we need Refresh Tokens?
Access tokens are bearer tokens which means that whoever has the token can use it. Therefore, if the access token is stolen then the attacker can impersonate the user for as long as that token is valid. To combat this, access tokens are given a short lifespan so that if it is stolen the attacker only has access for the life span of the token. However, because access tokens have a short lifespan, we need a way to get a new access token without prompting the user to log back in with their credentials each time it expires. This is what refresh tokens do. Once the access token has expired, the refresh token will be used to get a new one.
Refresh Token Theft
Of course, refresh tokens can be stolen too and if this happens then an attacker can obtain access tokens freely. However, the key difference is that refresh tokens can be revoked while access tokens can not. If a refresh token is stolen it can be revoked and the user can log back in with their credentials to retrieve a new one. Furthermore, refresh tokens are a lot less likely to be stolen as they are sent over the wire much less than access tokens. Refresh tokens are only used when the user needs a new access token, access tokens are sent with every request to get a protected resource. This can be done by storing both the refresh token and access token in HTTP cookies but setting the path for the refresh token to only be the location of the refresh route.
Storing Refresh Tokens
Refresh tokens are stored on the client, but they also need to be stored on the server. This is so they can be invalidated if they are believed to have been compromised. For example, say that a refresh token is being sent from a different IP address than it normally is, the account this refresh token belongs to can be promted through email or SMS asking if this is them. If they say it is not, we would need to look up the refresh token associated with that user and remove it. The refresh token could be stored in memory with Redis or a hash of the refresh token could be stored inside a database. Both would be linked to a user ID.