Reputation: 14230
I understand that the authentication process with access/refresh tokens works like this:
Process to manage/revoke access:
DB interactions: Only needed for refreshing tokens. i.e. frequency depends on the access_token lifetime.
User Experience: Login required when
Security implications:
Without refresh_token: +No long lived vulnerability -Bad UX. User needs to login frequently
Now I am wondering why we cannot just use the access_token as the refresh_token:
Now UX/security/DB_call_frequency seem to be identical. So why do we need a seperate refresh_token?
The only argument I can see is that separating them reduces the risk that a refresh_token gets stolen because it is sent less frequently.
Upvotes: 0
Views: 105
Reputation: 606
Create new access_token and set revoked for old token. (optionally, only allow this for x time after expiration. This is the equivalent to an expiration date for the refresh_token)
You wanted to do this again by exchanging username and password?
If so then user needs to login again. You can use Client Credentials Grant https://www.rfc-editor.org/rfc/rfc6749#section-4.4 or Implicit flow https://www.rfc-editor.org/rfc/rfc6749#section-4.2 which sends access token only, these flows doesn't send refresh tokens. If you can send username and password, you can use Client credentials grant and request access tokens every time it gets expired.
Upvotes: 0