When securing REST APIs for mobile applications, what you often see is the use of refresh tokens. They exist because:
- Access Tokens have expiration date.
- 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.