Should access tokens be refreshed automatically or manually?

Question

In the last few days I've been reading on Authentication with refresh and access tokens, but this is one thing I can't find the answer to. Let's say an expired access token is sent. Should the backend automatically refresh it (if a refresh token was provided), or the refreshing should only be done at a refresh endpoint?

As an example, consider the two following auth flows:

Automatically Refreshing

0. User authenticates with username and password. The API sends back a short lived access token containing his data, and a long lived refresh token.
1. For every request that requires authentication/authorization, the user will send both tokens on the request headers.
2. If the access token is expired, the API will check if a valid refresh token was sent, if it is active and if it belongs to the same user as the access token. If everything looks good then it will sign a new access token and update the response headers with it.

Front-end doesn't have to worry about refreshing the token, but it still has to look up response headers after each request to check if a new token was sent.

Manually Refreshing

0. User authenticates with username and password. The API sends back a short lived access token containing his data, and a long lived refresh token.
1. For every request that requires authentication/authorization, the user will send his access token.
2. When the access token expires, the user will send his refresh token to the refresh/ route. The API checks if the token is valid. If everything looks good, it returns a new access token.

After every request, the client has to check if the token expired, and if it did it will have to perform a new request to refresh the token. More requests are being made to the server, but on the other hand responsibilities are better separated, since auth route is only responsible for handling access tokens, while the refresh token handling lives in another route.

I've had some hard time finding resources on the subject, so I'm not quite about sure which solution is better, or even if the solutions I described are correct at all. If I had to pick one, I would go with Automatically Refreshing, since less requests are made, and the client side usability looks better, but as I said, I'm not 100% on this, and thus I'm making that thread.

How should access tokens be refreshed?

Answer 1

It feels to me that you are missing a role here, which is that of the Authorization Server (AS):

• UI redirects to AS to authenticate the user via password
• AS issues an access token and refresh token, then returns them to the UI
• UI calls the API for a while with the access token
• Eventually the access token expires and the API returns a 401 response
• The UI then calls the AS with the refresh the token to get a new access token
• The UI then retries the API call with the new access token
• Eventually the refresh token expires and the refresh attempt will fail
• The UI then redirects the user to sign in again and the cycle repeats

It is always the client's responsibility to refresh tokens and only the access token should be sent to the API. The API's only OAuth job is verify the access token and authorize based on its contents.

It is possible that you have an API that is doing the job of the Authorization Server. I would aim to separate these roles.

Answer 2

The implementations of the OAuth2-protocol I know use the flow you are describing under "Manual Refreshing". The client has to care himself about the refreshing.

The client can either check the access_token if it is still valid before every request or do a refresh after a failed request due to an invalid token response.

The access_token is short lived and so the risk sending it with every request and having it eavesdropped and misused is limited. The refresh_token is long lived. If you send the refresh_token with every request an attacker has a much greater chance to get hold of it.

If you send both token with every request you would not need the distinction between these two types. You would work with one long lived token only.