Funtov Kirill
TTCTheo's Typesafe Cult
•Created by Jimmy Page on 12/27/2024 in #questions
JWT with long-lived Refresh Tokens
"Need" is a strong word. The security have some trade-offs. It could be UX (you must relogin often or use 2fa), or some compute time or both.
There is no "need" in that. You go as far as you deem neccessary for your project.
But the question was - why not use just one long-live token?
And the answer is - it is less secure, since you can't have different policies (like one-time use and short-lived).
The process of black-listing is a separate topic - and do you want to store blacklist access tokens and check the list every request - is similarly - how much security do you want. Google opts to revoke all access immediately.
76 replies
TTCTheo's Typesafe Cult
•Created by Jimmy Page on 12/27/2024 in #questions
JWT with long-lived Refresh Tokens
As I understand, the purpose of refresh and access tokens are mainly security, not to lessen the compute time.
You have an access token that is:
* giving you access to stuff
* can be used in parallel
* you send it in almost every request
* BUT it is short-leaved
Refresh tokens are:
* far more dangerous
* they give you longer access to basically everything (via acquiring the access tokens)
* SO usually there are additional strategies to secure them, that would not work with access tokens
For example, best practice is one-time-use refresh tokens.
When you use a refresh token to get an access token, you actually get both (new refresh token too). And the old one is no longer valid.
So even if you leaked it - it would be dangerous for the time of life of access token.
This strategy can't be useful with access tokens, since they are usually sent in parallel.
76 replies