Why do I need Refresh Token if there is Access Token?

Recently, we at Voximplant improved authorization in the SDK. Looking at the results, I was somewhat saddened that instead of a simple and understandable token there were two of them: access token and refresh token. Not only do they have to be regularly updated, so they should also be documented and explained in the training materials . Remembering that in OAuth two tokens are needed mainly because of the different services on which they are used (there is even a stackoverflow question), and we have one such service, I went a little bit wow and went to the second floor to shake the souls out of the developers. The answer was unexpected. It is not on stackoverflow. But he is under the cut.

Why do we need tokens?

When developing applications that communicate with the server, the following steps usually come out:

1. The application is developed by one developer, there is no identification, no authentication, no authorization (by the way, I recommend a great Habrastija on this topic from DataArt ), requests go directly to the endpoints of the server, the developer is happy.
   
   
2. A second developer, or tester, or customer appears. It becomes important for the server to know who exactly is sending the request. An identification step is added: a simple window “introduce yourself” before launching the application and shouts “who again went under three ones and broke everything?!?”
   
   
3. When a team gets a little tired from “who came under three ones,” they will write a registration form with a login password on the backend, which will check for the uniqueness of the login. In this form, the product will be developed before the first beta version.
   ')
   
4. In the first beta version it turns out that storing the password in plain text on the device is somehow not very safe. A spherical user in a vacuum has one password from most services, and really do not want to be extreme, through whom the user hacked email, contact and everything else. Begin the search for a solution "to make it so that the password is not stored explicitly." And after some time, the team comes to one or another option "auth token".

Why do we need the first token

There are many different tokens. Ordinary, cryptographic, “access key”, “session token”, different acquisition, use and revoke schemes. At the same time, one of the key ideas is that if someone bad gets someone else's token, the most unpleasant thing that will happen is the access of the kidnapper to the service from which the token is stolen. The thief will not receive the password, the one that is used for all services. And the user, if he realizes that, besides him, someone else has access to the service, he can withdraw the token. Then get yourself a new one, having a login and password.

Why do you need a second token

In OAuth 2 and some other authorization schemes (for example, we ) have not one, but two tokens. The first, access token , is used when requesting the server (for example, when logging in). He has two properties: he is reusable and short-lived. Our, for example, lives 48 hours, and someone has 30 minutes. Time is selected based on how the service is used. The second, refresh token , is used to update a pair of access and refresh tokens. It also has two properties opposite to the first token: it is disposable and long-lived. Very long-lived, ours lives a month.

The usage pattern for tokens is as follows:

• The user logs in to the application, passing the username and password to the server. They are not stored on the device, and the server returns two tokens and their lifetime
• The application saves tokens and uses access token for subsequent requests.
• When the access token lifetime comes to an end (the application can check the lifetime itself, or wait until the server uses the answer “oh, everything” during the next use), the application uses the refresh token to refresh both tokens and continue using the new access token

Something like this is all explained in the OAuth documentation, on Wikipedia, in our documentation. And such an explanation does not answer the question what for?!? Why do we need two tokens, if you can do with one? In the question on stackoverflow, several explanations of the level “well, access token can be stored less reliably than the refresh token and not be afraid to use outside HTTPS connections. For example, store access token on the frontend, and refresh token on the backend ”or“ refresh token is used to access a deliberately secure service, and then you can poke the access token into all sorts of suspicious places and not be afraid that it will be merged ”. This may be reasonable for authorization through Facebook and subsequent use without HTTPS. But we have HTTPS everywhere! And we also have one service, ours. Why do we need a second token?

Why really need a second token

Everything turned out to be both simpler and more complicated than I thought. Watch your hands:

Case 1: Bob recognized both Alice's tokens and did not use the refresh

In this case, Bob will get access to the service for a lifetime access token . As soon as it expires, the application used by Alice will use the refresh token , the server will return a new pair of tokens, and those that Bob has learned will turn into a pumpkin.

Case 2: Bob recognized both Alice's tokens and took advantage of the refresh.

In this case, both Alice's tokens turn into a pumpkin, the application prompts her to log in with a login and password, the server returns a new pair of tokens, and those that Bob has learned will turn into a pumpkin again (there is a nuance with the device id that can return the same pair as in Bob. In this case, the following use of the refresh token will turn Bob's tokens into what is shown on the right).

Thus, the refresh + access token scheme limits the time for which an attacker can access the service. Compared with a single token that an attacker can use for weeks, and no one will know about it.