I am slowly getting a hang of authentication with Microservices, but I encountered a rather fundamental issue. My hypothetical architecture is as follows, a auth microservice, handling registration, login, token refresh, and a TODOS microservice handling users' todos.
I want to use short-lived JWT's alongside refresh tokens.
How are refresh tokens used? Since JWT's expire so quickly (couple of minutes), do I make a request to todos, and in the meantime if the JWT expired, I send back an error (Unauthorized or JWT expired specific error?) and then do I go back to auth service to refresh and then again somehow call the API? Do I pool on the client and check periodically if the JWT has expired?
These are some of my questions but it basically boils down to
- How do I handle JWT expiring? (During an API Call and while idling)
- Do I return a specific error that JWT has expired or just 403?
- How to handle these roundtrips (if that's the way to go), between getting 403, then to auth to refresh then back to the call?
CodePudding user response：
So your callers own access token and refresh token.
When a caller wants to call an api, they will use access token. The receiver will validate the access token (incl. expiry) and will answer "access denied" if the access token is not valid any more.
When a client gets access denied, they use refresh token to get a new access token.
The question is why refresh token is needed? As you said - access token is short lived. Why so? After access token is created, every resource/api can validate it. But there is no way to revoke the access token (options with revoked list are quite complicated to implement correctly); hence, instead of revocation we use shorted lived access tokens.
Since access token is shorted lived, it will be a poor customer experience if they constantly asked to approve another token; and this is impossible if access token is used to do some stuff on behalf of customers. To resolve this issue we have refresh token. Refresh token is used to get a new access token.
The most important property of using the refresh token: that's the moment when the token provider has a chance to revoke access - the provider may decide that this refresh token is not good anymore, e.g. because the customer decided to stop access.
To your question:
- How do I handle JWT expiring? (During an API Call and while idling)
You call the api with the access token, and if you get access denied, you use refresh token to get a new access token. This is the simplest way. As an alternative, you could use a backend job to refresh access tokens as they get expired. This is clearly more complex.
- Do I return a specific error that JWT has expired or just 403?
I wouldn't. If access is denied, it is denied.
- How to handle these roundtrips (if that's the way to go), between getting 403, then to auth to refresh then back to the call?
Not sure what do you mean. My code (in this use cases) has a simple handle - if access is denied, then use refresh token to get new access token; and then cache the access token.