Jimmy Page
TTCTheo's Typesafe Cult
•Created by Jimmy Page on 12/27/2024 in #questions
JWT with long-lived Refresh Tokens
I've been struggling to understand the purpose of short-lived access tokens and long-lived refresh tokens for a while now. I haven't been able to find many in-depth writeups about why the pattern is recommended and less so about how to use it in a meaningful way. I understood the gist of it - you'd want short-lived access tokens so if it's compromised, the bad actor only has a limited timeframe to cause damage. What I didn't understand is how that would prevent the same issue from happening with a long-lived refresh token.
I did some digging and this is what I concluded: https://medium.com/@getintheshell/finally-understanding-the-benefits-of-a-long-lived-refresh-token-bf021176a9d1
Basically:
- Short-lived access token to make auth stateless on the server. No need to query a DB for every API call.
- Long-lived refresh tokens to send out new access tokens.
- Blacklist for refresh tokens. If a token is compromised, we can add the refresh token to the blacklist to prevent it from generating any new access tokens. This will require a query to the blacklist every time the refresh API is invoked. This is fine because querying once for refresh is faster than querying for every API call for auth.
I thought I finally understood but then someone left a comment on my medium post that completely stumped me and now I'm back to square one.
Their question:
I am using google oauth and it provides me with refresh and access tokens. I just revoked access of the credentials directly from my google account which should have made the refresh token invalid. Now, the access token is immediately not able to access google apis. Do you have anything to add on this front? According to this article, I should still be able to access the google APIs for 4 hours(life of google access tokens) without any issues.If Google stores the access tokens in the blacklist, why not just use a long-lived access token? This seems very much like a stateful approach, no? I guess they could be using the access tokens for the claims so they don't have to query the DB for the user's access permissions, but at that point, why not just make the access token long-lived and remove the refresh token entirely? If a long-lived access token is compromised, why not just blacklist the access token? Seems like it would have the same end result.
76 replies