A few questions about json web tokens

Question

I have recently started using json web tokens and I have a few unanswered questions

1. what would happen if a users token expires while they are online? would they be forced to log in again when they request the next protected route? and if so it feels like there has to be a way around this so that the user does not randomly get logged out

2. how would you log someone out before the jwts expiration date considering the client holds all the info

any clarification on those 2 questions would be appreciated

Answer 1

what would happen if a users token expires while they are online? would they be forced to log in again when they request the next protected route? and if so it feels like there has to be a way around this so that the user does not randomly get logged out

When you make a request in a webapp, you need to pull in the available token. So the answer is "what does your app do?". There are lots of things you can do, such as making the request with the invalid token, or no token at all. But obviously that's not really a good idea. The best strategy is to:

1. Before every API call needing a token, check if the current token is valid
2. If the token isn't valid ask your auth provider to get a new token. This is known as silent authentication. How the provider handles this is totally up to them, usually they have a HttpOnly cookie saved for a secure domain, and return a new JWT.
3. If the silent auth fails, then the provider will tell you to log the user in.
4. At this point the best course of action is to redirect to the user to the auth provider using the same "login strategy" they previously used, to get a new "session" and a new "token".

how would you log someone out before the jwts expiration date considering the client holds all the info

Logging out is completely separate from token expiration. Logging out from a user standpoint is:

1. Tell the auth provider to remove the HttpOnly secure cookie
2. Delete the JWT in the browser
3. Change the UI to display the user as no longer logged in.

But that doesn't expire the token. The token will always be valid until the exp date. If you want to also prevent that token being used as if it was valid, you must deny-list the token using your AuthZ IAM as a service. For instance, if you were using Authress to manage access control, a DELETE https://api.authress.io/v1/users/{userId}/tokens/{tokenId} would cause subsequent checks using that token to return Forbidden. However, I will stress, the token is still valid, but you've taken the step to mark it as Deny-listed.

Answer 2

would they be forced to log in again when they request the next protected route?

If there is no other information that associates the session with the logged-in user (for example, there aren't any cookies or other tokens the server can use), yes.

Yeah, it's not very user-friendly, and JWTs often have a short expiry time. A common solution to this issue is to provide a refresh token as well, which could be stored in a HttpOnly cookie:

A refresh token has 2 properties:

1. It can be used to make an API call (say, /refresh_token) to fetch a new JWT token before the previous JWT expires.

2. It can be safely persisted across sessions on the client!

This way, the client can always have a valid JWT at any one time; they won't have to log back in, or logout and then log back in.

how would you log someone out before the jwts expiration date considering the client holds all the info

You can implement logic on the server to somehow blacklist or ignore the JWT from a particular user until they log in again. For example, after parsing the JWT, you could check to see whether the server considers the token to still be usable or not. If not, return a 401 error.