A good auth system contains access and refresh tokens. I know what access-tokens are for and I know what refresh tokens DO - but I don't understand their meaning.

For example:
If I authenticate myself successfully to an API, then I get an access token and a refresh token. If a bad guy steals my access code, he can access the API maybe the next 5 minutes or so. But if he steals my refresh token which maybe expires in 6 months he can give himself every time a new access-token and so he can stay longer in the system.

So what are the advantages of refresh tokens - I don't see them?

  • a refresh token can have a much longer expiry than an access token. When the user open the app/webpage a week later, instead of being prompted for their username and password the app can use the refresh token to login. The refresh token is never sent to the resource, if you set a long timeout on the access token it would be insecure, the App also isn't supposed to know the users password in oauth2
    – Ewan
    Aug 30, 2021 at 12:06
  • dunno why this got downvoted?
    – Ewan
    Aug 30, 2021 at 12:08
  • 1
    Googling "refresh token" yields this search result, which explains how and why they are used, and how to use them securely. The tooltip on the downvote button reads "This question doesn't show any research effort." Aug 30, 2021 at 14:22

3 Answers 3


The key to systems with separate Access and Refresh tokens is that they involve three parties:

  • The client that wants to access some service
  • The service they want to access
  • A separate service which is in charge of authentication

Access Tokens are sent between the client and the service being accessed. They may even be passed around multiple services.

To keep things efficient, they may be stateless tokens such as JWT - the authorization data is encoded in the token itself in a tamper-proof way, so no access to a central database is needed to check the token. This comes with a cost: if the token leaks, an attacker can continue to use it. This means such tokens need to have a short lifetime - maybe even less than a minute, if the service is particularly sensitive.

The Refresh Token is how the client gets a new Access Token from the authentication server without asking the user for their login details every time. It is held closely by the client, and only ever sent back to the authentication server.

Unlike the Access Tokens, which are passed around many stateless services, Refresh Tokens have a stateful element on the authentication server - specifically, it can revoke tokens. That means that although the Refresh Token has a much longer lifespan than the Access Token, an attacker cannot use a compromised token indefinitely - the authentication server can detect suspicious behaviours, like the same Refresh Token being used more than once, and refuse to issue new Access Tokens without a fresh login. Similarly, it can check that the user still has permission for the requested resource, and hasn't been suspended, or explicitly requested a logout.

The lifetime of the Refresh Token also acts as a measure of the maximum idle time before the user must re-authenticate, like the timeout on a stateful session. For instance, a Refresh Token lifetime of 1 hour means the user can log in, walk away for 59 minutes, and then come back; the client will no longer have any valid Access Tokens, but the Refresh Token will still be accepted, so the user doesn't have to log back in.

The two tokens allow you to have a different balance of competing requirements: the efficiency and reasonable security of a short-lived stateless token, and the user-friendliness and reasonable security of a long-lived stateful token.


You don't have to use refresh tokens. The client could ask for username/password every time (which is annoying to the end user), or store the credentials, with the risk of leaking them. Passwords are often reused, so leaking one is rather dangerous. A refresh token is only valid for a single API, has a limited validity period (which can be controlled by the authentication server), can be invalidated without resetting someone's password. So it's a lot safer to store than a password.

  • But if I for example steal the refresh token, then I can generate myself a much longer time new access tokens. Isn't that a huge security issue?
    – Bamba675
    Sep 23, 2021 at 14:47
  • @Bamba675 yes, but less so than storing the password.
    – Glorfindel
    Sep 23, 2021 at 15:47
  • so why cant I just set the access-expire date long and dont user refresh token?
    – Bamba675
    Sep 28, 2021 at 15:35
  • That works, if you don't mind your users having to log in now and then.
    – Glorfindel
    Sep 28, 2021 at 16:06
  • With a long access-exire date, the session is long running (and can not be closed in the backend). With a refresh token, the refresh token aquires a regulare token first. That step could be controlled by the backens, so it could NOT allow a refresh. For example because the user was blocked by an admin a few minutes ago.
    – JanRecker
    Oct 26, 2021 at 9:25

One key advantage of refresh tokens that's being missed is that they are revokable, while the access token is not.

To authenticate the access token, only its signature is checked. This makes it extremely fast to authenticate, and allows authentication to be performed in a distributed manner by different services without needing to check with another server or database. This also means it needs to have a short expiration time in case it's compromised because it can't be revoked.

With refresh tokens, it's presumed that some database or authentication server needs to be contacted in order to generate a new access token. This means it's slow (relatively) and can't be done in a distributed manner. But the token can be revoked if the user account is compromised, or the user changes their password, or for any other reason.

If you want to just use an access token/api key you can. It just means you either have to lookup in a database to make sure the token is still valid, or set a short refresh rate and force the client to re-authenticate every time. If your application doesn't need the performance, or can tolerate re-authenticating frequently, or you don't care about revoking access tokens, then you don't need refresh tokens.

  • This is basically what I was trying to say in my answer, but explained much more concisely, so have an upvote. :)
    – IMSoP
    Oct 26, 2021 at 16:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.