What is the purpose of a "Refresh Token"?
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.
@Teyam mention SO post Why Does OAuth v2 Have Both Access and Refresh Tokens? but I prefer the another answer there: https://stackoverflow.com/a/12885823/254109
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.
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_tokenis only ever exchanged with authorization server whereas theaccess_tokenis 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?
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).