Let's assume API A gets handled by the server first. Both of these API calls are carrying the same expired access token and the refresh token (let's assume this refresh token is valid). At the time of triggering these two API calls, the access token was expired. Let's say the Client makes 2 API calls ( API A and API B) at the same time. If it helps my Messages Blog Post shows some example messages from a full UI and API solution.įollowing is the Main Disadvantage of using Automatic Refresh Token Rotation Scheme :. It is possible that you have an API that is doing the job of the Authorization Server. The API's only OAuth job is verify the access token and authorize based on its contents. It is always the client's responsibility to refresh tokens and only the access token should be sent to the API. The UI then redirects the user to sign in again and the cycle repeats.Eventually the refresh token expires and the refresh attempt will fail.The UI then retries the API call with the new access token.The UI then calls the AS with the refresh the token to get a new access token.Eventually the access token expires and the API returns a 401 response.UI calls the API for a while with the access token.AS issues an access token and refresh token, then returns them to the UI.UI redirects to AS to authenticate the user via password.It feels to me that you are missing a role here, which is that of the Authorization Server (AS): 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. 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. 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. If everything looks good, it returns a new access token.Īfter 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. When the access token expires, the user will send his refresh token to the refresh/ route.For every request that requires authentication/authorization, the user will send his access token.If everything looks good then it will sign a new access token and update the response headers with it.įront-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. 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.For every request that requires authentication/authorization, the user will send both tokens on the request headers. The API sends back a short lived access token containing his data, and a long lived refresh token. User authenticates with username and password.Should the backend automatically refresh it (if a refresh token was provided), or the refreshing should only be done at a refresh endpoint?Īs an example, consider the two following auth flows: Automatically Refreshing Let's say an expired access token is sent. 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.
0 Comments
Leave a Reply. |