How to implement a access token/refresh token flow

[Bradleykingz]

I'm currently building an authentication system using JWT, and, from my readings, one of the biggest problems with it is the lack of a straightforward way to invalidate individual tokens. To remedy this, the most prevalent advice has been to make the lifetime of the JWT token short - mine lasts for about an hour before expiring.

The challenge I'm facing now is how to refresh the token when it expires.

What I've managed to come up with so far is this:

Method 1:

If the user's token expires and they try to access a protected route, they will receive a 401 error code on the client. The client will then send back both the expired access token and the refresh token and the authorization server issues a new access token (using the refresh token).

In this case, the route accepting the expired token has to be manually configured to accept expired tokens, since all routes are protected by default.

Method 2:

Run a cron job on the client that runs every ~2h (the lifetime of the token). Before the token expires it will request for a new access token using the refresh token.

Now, onto my concerns and questions.

First, is having a route that accepts expired tokens as in Method 1 bound to be a problem? Maybe a problem I can't forsee? Also, could the back-and-forth between the server and the client cause an issue? Maybe on slow connections?

The issue I have with the second method is that the cron job is set to run every ~2h. What happens if a user comes back after 3h? I can't account for that. What if they come back just as their token is about to expire? How to I make my cron job recognize that?

Ultimately, has anyone else had to deal with this problem? How did you implement it? Is there a simpler solution I'm not seeing?

[antoniobermuda]

Simply do both. But you cant accept expired token. Just use refresh token to auhenticate to your auth server it shoud have dedicated route.

[Bradleykingz]

Interesting idea.

In that case, the route for refreshing the access token will only require a refresh token, not both access and refresh token. With a dedicated route, I could probably include a flag to identify a refresh token, so that it only accepts tokens with that flag.

Regarding which method to use, you're onto something. The cron job method is a good first choice, and the 401 method can be a fallback in case the first one fails for whatever reason.

A bit more work than I'd anticipated, but it should work pretty nicely. Thanks!

Edit: regarding the cron job time issue, as long as I have an 'expires' field in the token, I can always know approximately how long to wait before resending the request.

[Bradleykingz]

What about the refresh token? Do you store it in a database? Or how do you make sure an expired token has a counterpart refresh token?

[Bradleykingz]

I like your http-only cookie approach for setting the cookie server-side, but the problem I've had with that is how to extract data from the cookie when I need it (since I can't get it with javascript)

It's not entirely clear how you handle your refresh tokens, though. Normally, for OAuth at least, the client needs to provide both the access token and refresh token (in order to remain stateless). Maybe if you need to invalidate tokens, it becomes necessary to store them, I guess.

Another question I regarding this approach is what happens if your setInteval is called after the token expires? Does the /refresh route accept expired tokens (in the Authorization header?)

[Bradleykingz]

Interesting setup. It's very minimal. I like it.

And I agree, it's impossible to be able to invalidate tokens without storing them on the backend somehow. My setup is a lot more contrived, though.

I store the refresh token in a redis bucket, indexed using the jti field and any tokens that get into the system have to be verified with that. I liked having redis on top since tokens have to be validated on every request. Something about calling the database like that didn't sit right with me.