What is the purpose of a "Refresh Token"?

Question

I have a program that integrates with the YouTube Live Streaming API. It runs on timers, so its been relatively easy for me to program in to fetch a new Access Token every 50 minutes with a Refresh Token. My question is, why?

When I authenticated with YouTube, it gave me a Refresh Token. I then use this refresh token to get a new Access Token about once an hour. If I have the Refresh Token, I can ALWAYS use this to get a new Access Token, since it never expires. So I don't see how this is any more secure than just giving me an Access Token from the start and not bothering with the whole Refresh Token system.

Amadus

See https://mcmap.net/q/47888/-why-does-oauth-v2-have-both-access-and-refresh-tokens – Moly

Access token are bearer tokens. Meaning no other identification is required, and the access token is all that is needed to impersonate you. Because of this, they should always remain short lived. On the other hand refresh tokens are not bearer tokens. When you send a refresh token to YouTube to get a new access token, you also have to send a client_id and client_secret. Because of this, refresh token can remain longer lived because it is much less likely that both the refresh token and the client_secret would be compromised. – Lewse

@Lewse Why is it less likely that the refresh token and client_secret would be compromised? All tokens, including access tokens, are send over HTTPS, I assume, so they are always encrypted. – Freeload

@OlleHärstedt, less likely to be compromised in two ways I guess. First, because they spend much less time being sent over the wire then access tokens - an attacker mounting a MITM attack (or some other type), has less opportunities to obtain them. Second, if an attacker was to gain some access to the server, they would need to obtain 3 pieces of information (token, id, and secret) as opposed to just one (access token), which, theoretically, seems harder to do. – Lewse

tokens can be tied to ipaddress as well so its add extra layer of security – Soubrette

Answer 1

Basically, refresh tokens are used to get new access token.

To clearly differentiate these two tokens and avoid getting mixed up, here are their functions given in The OAuth 2.0 Authorization Framework:

• Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.
• Refresh Tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope.

Now, to answer your question on why you were still being issued a refresh token instead of just securing an access token, the main reason provided by Internet Engineering Task Force in Refresh tokens is:

There is a security reason, the refresh_token is only ever exchanged with authorization server whereas the access_token is exchanged with resource servers. This mitigates the risk of a long-lived access_token leaking in the "an access token good for an hour, with a refresh token good for a year or good-till-revoked" vs "an access token good-till-revoked without a refresh token."

For a more detailed and complete information of OAuth 2.0 Flow, please try going through the following references:

• OAuth 2.0 Flow: Server-side web apps
• The OAuth 2.0 Authorization Framework issued by Internet Engineering Task Force (IETF)
• SO post - Why Does OAuth v2 Have Both Access and Refresh Tokens?

Sinh

Should refresh token also help get new refresh token? – Infundibulum

Why just not acquire a new short-lived access_token when it expires? Why to have the long lived refresh_token if you need to request the server for a new access_token anyway? Or is it true that with a refresh_token I don't need to maintain alive identity provider cookie and it issues new access_tokens based on the refresh_token even after the cookie has long gone and the user would have to enter his credentials if they wanted to get a new access_token? – Discontent

@Discontent As an OAuth2 Client, without a refresh token, I would need to initiate the whole authorization flow again (getting the user to 'login' and give me permissions again), in order to get another access token. Refresh tokens bypass this requirement as a sort of 'proof' that I, as the Client, have already received the User's permission to request an access token. – Lewse

can a refresh token have identical or same data as the access token? since the major use of refresh token is to ease user experience and limit hackers' access time to a resource. – Upbeat

This answer focuses a lot on the "what" and very little on the "why". I think a real-world example would benefit readers. – Marlowe

@Sammy Taylor completely agree. I can't believe I read that whole wall of text just to arrive at absolutely nothing – Peal

Sorry, I just answered the original question. You may want to check the other answers. – Sinh

With client credentials grant flow, there's no need to use a refresh token. Just re-request the access token. – Virelay

What if the same server is used as authorization and resource server. – Claypool

Answer 2

The refresh token serves at least two purposes. First, the refresh token is a kind of 'proof' that an OAuth2 Client has already received permission from the user to access their data, and so can request a new access token again without requiring the user to go through the whole OAuth2 flow. And second, it helps increase the whole flow of security when compared with a long lived access token. I'll touch on both of these points in a little more detail.

Refresh Tokens as a Means to Not Annoy the User

Let's talk about the first purpose with an example. Suppose you, a User, were using a third party Client web application that wanted to interact with your YouTube account data. Once you grant permission to the Client application to use your YouTube data, would you want the Client app to prompt you for your permission again when its YouTube token expired? What happens if the YouTube token expiry time was something very low, like 5 minutes. It would get a little annoying having the Client application prompt you for your permission at least every 5 minutes! The solution that OAuth2 proposes to this 'problem' is refresh tokens. By using refresh tokens, the access token can remain short-lived (which is desirable in case the access token is leaked or stolen somehow), and the refresh token can remain long(er)-lived, allowing the Client to get a new access token when one expires without requiring the user's permission (again).

But why a refresh token? If the point is to not bug the User with permission requests, then why can't the Client simply say "Hey, Authorization Server, I want another access token. Now!"? Or, "Hey Authorization Server, here is my expired token, give me a new one!". Well, the refresh token serves as a kind of "proof" that the Client at some original point in time was granted access by a User. This "proof" is in the form of the refresh token being digitally signed by the Authorization Server. By the Client presenting a refresh token, the Authorization Server can verify that the Client received, at some point in the past, permission from the User, and the Client does not have to prompt the User again.

Refresh Token as a Means to Increase Security

However, this raises the question, "Well, what happens if the refresh token is leaked or stolen, or simply kept by a malicious Client application that doesn't get rid of it at the user's request? Can't the attacker just continue to use the refresh token to gain a valid access token indefinitely (or until it expires)? This question leads to discussing the second purpose that I mentioned, of refresh tokens contributing to a more secure flow.

The issue that arises with access tokens is that, once acquired, they only ever get presented to the Resource Server (YouTube for example). So if an access token is stolen or compromised, how do you tell the Resource Server not to trust that token? Well, you can't really. The only way to do it would be to change the private signing key on the Authorization Server (the key that signed the token in the first place). I imagine this is inconvenient to do, and in some cases (like Auth0), is not supported.

On the other hand, refresh tokens need to be presented to the Authorization Server frequently, and so if one is compromised, then it is trivial to revoke or deny the refresh token as a whole, and not have to change any signing keys.

Lewse

Means to not annoy the user explained this for me. In my context I'm hitting an API from a web back-end so I never have to enter credentials manually, they are available in the application. I always wondered, why not just get a new token each time with my credentials, why store a refresh token and track its expiration. I never thought that in a user workflow where credentials are hand-entered this would be highly annoying. – Testimonial

@Testimonial in a simple login scenario like login with username and password you are right, but in more complex ones like login with OTP or OAuth2 flow, refresh_token is required – Sankhya

@Lewse According to the answer you posted, is it true to say that if in a case the resource server and the authorization server are same (I mean that for example a website that deliver resources and also do authorization itself), using refresh-tokens are not so meaningful? – Kwapong

Answer 3

Here is the information from the OAuth 2.0 documentation.

Refresh tokens are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner).

  +--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+

(A) The client requests an access token by authenticating with the authorization server and presenting an authorization grant.

(B) The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token and a refresh token.

(C) The client makes a protected resource request to the resource server by presenting the access token.

(D) The resource server validates the access token, and if valid, serves the request.

(E) Steps (C) and (D) repeat until the access token expires. If the client knows the access token expired, it skips to step (G); otherwise, it makes another protected resource request.

(F) Since the access token is invalid, the resource server returns an invalid token error.

(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).

Lat

I have having a doubt in the last step. Is sending refresh token using refresh token bad practise? should I not do that? – Thermionic

@VigneshS I didn't get your question... If your session is about to expire, you send refresh token to get new access and refresh tokens. – Lat

@DennisMeissel can you explain to me what is the new access token re-issued by sending refresh token ? is it will be used the current refresh token as new access token ? example I have current refresh token is 123, after re-issued the new access token, i will receive 123 as a value of new access token ? – Jenine

@Jenine no, after you send a valid refresh token to the authorization server, the authorization server starts the refreshing process: it generates a new access and optionally a new refresh token. At the same time, the used refresh token as well as the old access token expire. However the old access tokens not always expire after the refreshment, it depends on the implementation. – Lat

Since the refresh token is only ever communicated between the client and the auth server, could/should it live in a HttpOnly cookie? To make it more difficult to accidentally leak this data. – Farina

Answer 4

Using only Access Token is much more risky than using both Access Token and Refresh Token.

For example, you use only Access Token set "100 days" expiry date but one day, Access Token is stolen by a hacker. Now, the hacker has the big chance to freely use the Access Token for 100 days as a maximum for bad purposes.

Now, you use both Access Token set "60 minutes" expiry date and Refresh Token set "100 days" expiry date but one day, Access Token is stolen by a hacker. Now, the hacker has much smaller chance to freely use the Access Token for 60 minutes as a maximum for bad purposes.

Now, you will think if Refresh Token is stolen. Actually, if Refresh Token is stolen by a hacker, the hacker still has the big chance to freely use the Refresh Token for 100 days as a maximum for bad purposes. But the probability which Refresh Token is stolen is much less than Access Token is stolen because Refresh Token is used only once every 60 minutes to refresh Access Token(to get a new Access Token) while Access Token is used every time you access resources which is much more frequent.

So, you better use both Access Token and Refresh Token.

Fulmis

Are there reliable solutions to prevent the attacker from getting that if he get access to the client data? Are there any measure that makes JWT secure even if the attacker gains access to the client? – Thirzi

Good answer. Another point about long expirations is that you can't revoke them easily. Keeping access tokens short-lived, means you can revoke the refresh token, and then the hacker will only have access for the short-lived amount of time. – Riptide

Answer 5

@Teyam mention SO post Why Does OAuth v2 Have Both Access and Refresh Tokens? but I prefer the another answer there: https://mcmap.net/q/47888/-why-does-oauth-v2-have-both-access-and-refresh-tokens

TL;DR refresh_token does not bring increased security. It's for the purpose to improve scalability and performance. Then, access_token may be stored just in some fast, temporary storage (like memory). It allows the authorization and resource server separation, too.

Bahamas

except there is a security reason, as mentioned by @Teyam: "refresh_token is only ever exchanged with authorization server whereas the access_token is exchanged with resource servers" – Jacynth

This is only more secure if we assume the authorization server is somehow better secured as the resource server. If this is not the case it is actually less secure. It the refresh token is compromised I can just use that to get a new access token. – Dianndianna

TL;DR ?? is it really ? – Lovelady

I like the emphasis on scalability, I think this is often missunderstood, I summarize it here: https://mcmap.net/q/47888/-why-does-oauth-v2-have-both-access-and-refresh-tokens – Anywise

Answer 6

access_tokens are more frequently used, and ability to revoke is not very important since they are short lived.

refresh_tokens are less frequently used, and the ability to revoke is crucial since they can be used to generate new access_tokens.

Validating a signed token is less costly, but revoking is difficult.

Validating a token stored in a database is costly, but can be easily revoked.

So, signed keys can be used as access_tokens to improve performance.

Db stored keys can be used as refresh_tokens, to make it easy to revoke them.

If there was no refresh_token, it is hard to find a mechanism which provides low cost validation and easy revocation ability. So refresh_token exists due to performance reasons.

Matriculate

Is it also correct to assume that because refresh tokens are used less often in requests, they are less likely to be intercepted? – Humidifier

Good answer. Refresh tokens should be treated like passwords and have expensive validation. – Zeph

best answer. it actually explains the pros and cons – Rubdown

Answer 7

"So I don't see how this is any more secure than just giving me an Access Token from the start and not bothering with the whole Refresh Token system." I struggled with the same question. The short answer is the refresh token is necessary to assure the credentials have not expired.

An example may help: I have a database that stores your medical records. You consent to sharing your medical records with your spouse. Your spouse uses their Access Token to read your records from my database. Two weeks from now your spouse checks again on your medical records and the refresh token is used to ensure they still have permission (from the authentication server) to view your records. The refresh token bypasses the need for your spouse to re-enter their credentials (username and password) to the authentication server, but it does ensure they still have legitimacy to access the resource. A never expiring Access Token would not know if you had revoked your spouse's rights to access your medical records.

Bari

Wouldn't the access token be invalid if I have revoked my spouse's rights to access my medical records even if its never expiring? – Thundery

access token are short lived usually around 30 to 60 minutes & it is highly unlikely that someone grant a client-app authorization to their data (secured resource) and revoke it within that 30-60 minutes. But if the user did revoke then the authorization server will revoke the access-token & refresh-token. Also a good client-app should also voluntarily invoke the /revoke endpoint to give up the tokens when the receiver (in this example the spouse) decides that she/he no longer needs access to the secured resources. This way no valid tokens are lying around when they are no longer needed. – Drama

Answer 8

There are at least 3 somewhat related reasons for having short-lived access tokens and long lived refresh tokens.

Bearer Tokens

From the original question:

If I have the Refresh Token, I can ALWAYS use this to get a new Access Token, since it never expires.

Although you may always be able to get a new access token using a refresh token, an attacker may generally not. This is because your use of the refresh token is coupled with some proof of your identity as a client, e.g. by providing your client_secret. Such proof is not needed for access tokens, which are bearer tokens, i.e. simply presenting them is enough.

Having the access token be short-lived mitigates this otherwise unlimited power of access tokens somewhat.

Surface of attack

Access tokens are exchanged with (potentially many) resource servers, which increases the chance of leakage. refresh tokens are only ever exchanged with the authorization server.

Again, the short-livedness of access tokens is at least some level of mitigation.

Revocation

It is possible (and common) to implement access tokens as signed JWTs. In that scenario, any server (that knows the public key of the signing party, which is typically in some well known location) can validate the correctness of the access token independently. This allows for nicely decoupled architectures, in the sense that the resource servers don't have to ask the authorization server about authorization.

The drawback of such a setup is that such tokens cannot be revoked (without anything as drastic as revoking the public key of the authorization server).

By having the access tokens be short lived, they can simply be allowed to run out rather than revoked explicitly.

Comp

Answer 9

The access token have a short life span. Once, it expires you need a new access token to access protected resource. One way to obtain a new access token authenticate resource owner again and get authorization grant then obtain access token. However, this will be annoying.

This problem can be solve with refresh token. It has long life span. So you can use it to get new access token without interacting with resource owner.

Well, you may think what is the point of having token with long life-span to obtain another key with short life-span. Well, even refresh token is compromised, attacker cannot just obtain a access token from it. Reason is attacker need the client credentials along with that refresh token.

Therefore, the access token will have a short life-span(reasons for this are available in other answers) to improve the security. To avoid resource owner being annoying whenever the access token expires, OAuth is using refresh token.

Sputter

Answer 10

refresh_token pattern keeps the OAuth server in control so the server can intervene when something bad happens like access_token and refresh_token getting leaked.

e.g.

if access_token and refresh_token get into the hands of a hacker, access_token will expire shortly, the hacker might try to refresh the token but the server now has the capacity/control to not issue the access_token again (considering the server got information of the leak).

Binns