Small question about refresh tokens

[MoltenCoffee]

Hey! Thanks for the wonderful examples, they really were an eye opener for something I've lost some nights sleep over.

one thing I can't really get my head around is the sendRefreshToken() call in both the installCookieJWT middleware and refreshTokenPlugin schema extension. sendRefreshToken() is of course needed in refreshTokenPlugin, as otherwist the refresh token wouldn't be set at all, but do I read correctly it's set in the former as well?

More to the point, am I correct in the assumption that you extend the expiry of the refresh-token every time a new access-token is set?

Thanks in advance!

[onpaws]

Hi, glad it's helping you! I had fun putting this together and pleased to see others benefitting also. It's been a little while so apologies for any mistakes in recollection.

Yes, I think you're correct in your analysis. I seem to recall settling on this approach because I liked the UX polish apollo-link-token-refresh brings to the table, and since I know it calls fetchAccessToken regularly, it's a useful already existing way to implicitly extend the refresh_token expiry. In other words, the /access_token route (which tbh could be named better) sets a fresh refresh_token not only when signing in but every time the access_token is refreshed.

While I find this to create a nice UX for people who access the app at least once a week, if it's important in your app to avoid this coupling -- to more deliberately control when refresh_tokens get issued -- I suppose you could parameterize the route or possibly separate it into two routes. If you end up pursuing this PRs are welcome :)

Hope this helps and good luck getting your 😴 pattern back on track ⚡

[MoltenCoffee]

Thanks for the response!

Our project at the moment doesn't use Apollo-client in favour of a slightly more lightweight solution, but perhaps this might still change. apollo-link-token-refresh does seem to solve the problem of potentially slow requests if a token happens to be expired when doing the request.

While looking around, I stumbled across this page in the Authlete docs. I am not familiar with Authlete at all, but they did mention three different ways of handling refresh tokens. I quote:

There are three choices for handling the used RT:

• Keeping the RT valid for the next token refresh,
• Making the RT invalid and creating a new RT with a predefined duration, or
• Making the RT invalid and creating a new RT with a remaining duration of the old RT.

I guess which one is right is, as always, a trade-off between security, stakes, risks, use case and UX. I think I might go with the last option for out project, which I think is just a case of reading exp on the verified token and set the same value on the new refresh token. That way we'll still have 'single use' refresh tokens, without an 'endless' login (provided weekly use).

Anyways, enough of my rambling. Thanks for the example and the response!