5

When securing REST APIs for mobile applications, what you often see is the use of refresh tokens. They exist because:

  1. Access Tokens have expiration date.
  2. We don't want the user to have to enter his credentials.

Refresh tokens are revokable tokens with no expiration dates that can be used to retrieve a new access token when the later has expired. See here.

On all your API calls, the (valid) access token will be sent. When it's expired, you use your "special key" (the refresh token) to get another not-expired access token.

How is this broadly used pattern anyhow inferior or different from just issuing a non-expiring access token and storing it in the device, just the same way you would have stored your refresh token?

PS: If your answer to this is that sending the non-expiring token on each request is less secure (middle man), I would argue: is it really when your API is over HTTPS? (Plus you do send an non-expiring token on the same network anyway, you just call it "refresh token" and send it less often).

PS2: If your answer relates to the ability to revoke refresh tokens, then I guess I could argue that we could make our access tokens revokable as well.

1

When working - for example - with JWT tokens, the tokens are self-signed.
Which means that the resource service can verify the token's integrity without having to communicate with the authentication server. Which is fine to do with short-lived access tokens.
But when the refresh token will be used to acquire a new access token from the authentication server, the authentication server could be performing more validation like checking if the session was revoked or if the user's account still exist, is still active and still has the rights to access the resource service for which it will issue a new access token.

In that case, using refresh and access tokens can help you implement simpler validation mechanisms for short-lived access tokens, allowing faster response from your resource server.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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