It seems I don't quite understand the idea behind the refresh token yet.

Assuming that a short-living access token is used, this token might get stolen, allowing the attacker to access the resource until it expires (maybe 3600 seconds).

But what if the attacker manages to steal the refresh token as well (shouldn't be more difficult as it is not more protected than the access token, right?)? Won't the attacker be able to simply get a new access token with it since no authentication is required for refreshing the access token when someone possesses a refresh token?

3 Answers 3


TL;DR: Yes refresh tokens are bearer token and so should be protected.

Refresh tokens are powerful because in general they are:

  • long term: meaning that they have long expiration times
  • privileged capability: meaning that they allow the bearer to renew their access token.

Refresh tokens are also bearer tokens, which means the service consuming the token will give access to the bearer of the token -- no questions asked. This is similar to access tokens.

So making sure bearer tokens are protected and stored securely is very important. The more critical a token, the better it should be protected.

As an example in OAuth2, implicit flow which is generally used with mobile apps, the client side app has a short lived access token. They are also generally not given a refresh token. Since a client side app can be easily compromised and any data/tokens be compromised, its bearer tokens have limited privilege and lifetime.

In contrast, in OAuth2 authorization code flow which is generally used with server side apps, the server app is given a longer lived access token or/and a refresh token. This is because it is assumed that server side is more trusted and less likely for it to be compromised. Having said that, server side tokens should still be stored securely given their usage pattern.

To summarize, when deciding what kind of tokens you need, check: - trust level of your client and the flow most appropriate for that trust level - protect your tokens!

  • 1
    Can you clarify: you mentioned that Refresh Token is also a bearer token, however tools.ietf.org/html/rfc6749#section-6 says "the refresh token is bound to the client to which it was issued. If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server" - so you must have client id and client secret in order to authorize, so that wouldn't purely rely on the the bearer alone, not? Jun 17, 2019 at 6:53

You are right, this is why refresh token should be stored securely. Maybe encrypting it inside a cookie with the secure flag enabled, so it is only transferred over HTTPS.


Refresh tokens are generally not bearer tokens. At least they're not based on the RFC 6749 spec. However, it really depends on the authorization server's implementation and policies. And, that's the crux of Oauth in general. Not everyone adheres to the spec.

Anyways, access tokens are generally bearer tokens and considered stateless. You send them to the resource server (the server hosting whatever API), and they will not care who you are.

However, a refresh token is NOT sent to a resource server. It's sent to an authorization server, and the refresh token generally has more security implementations to prevent abuse. As per RFC 6749 spec:

(G) The client requests a new access token by authenticating with the authorization server and presenting the refresh token. The client authentication requirements are based on the client type and on the authorization server policies.

(H) The authorization server authenticates the client and validates the refresh token, and if valid, issues a new access token (and, optionally, a new refresh token).

Generally, this requires a client ID and client secret to be sent for authentication to enforce refresh token / client binding. But, it goes even one step further:

(C) Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the redirection URI provided earlier (in the request or during client registration). The redirection URI includes an authorization code and any local state provided by the client earlier.

(D) The client requests an access token from the authorization server's token endpoint by including the authorization code received in the previous step. When making the request, the client authenticates with the authorization server. The client includes the redirection URI used to obtain the authorization code for verification.

(E) The authorization server authenticates the client, validates the authorization code, and ensures that the redirection URI received matches the URI used to redirect the client in step (C). If valid, the authorization server responds back with an access token and, optionally, a refresh token.

Basically, what this tells you is that any refresh token request must come from the same URI/URL as in the original redirection URI from the authorization code grant portion of a typical OAuth flow. So, what does this mean? Even if someone stole your refresh token, if the authorization server is implemented to the RFC spec, then it will throw an invalid_grant error if you try to make the request from another domain / URI. Of course, this is all with the caveat that the authorization provider implements the spec and policies to do this. Google definitely does this.

  • Counterpoint: auth0.com/blog/… "Refresh tokens are bearer tokens"
    – schroeder
    Jun 15, 2023 at 20:03
  • I saw that, and that's their implementation. But, read the spec. Refresh tokens are not supposed to be bearer tokens. At least not in OAuth 2.0. Also, to clear up any confusion: stackoverflow.com/questions/46782725/oauth-2-0-vs-auth0
    – David Ho
    Jun 15, 2023 at 21:16
  • So to say that refresh tokens are bearer tokens is not misinformation as you originally stated. It's just not the spec. A large Oauth implementation does indeed have refresh tokens as bearer tokens.
    – schroeder
    Jun 15, 2023 at 22:39
  • Regardless, stolen refresh tokens will NOT work with Oauth 2.0 compliant auth servers. Just try it with Google. It won't work.
    – David Ho
    Jun 16, 2023 at 23:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .