Jimmy Page
TTCTheo's Typesafe Cult
•Created by Jimmy Page on 12/27/2024 in #questions
JWT with long-lived Refresh Tokens
but would a user need more then 1 refresh token per deviceNo, a user won't need more than one refresh token per device but each user can have more than one device.
Also why do you want to keep track of all the previouse ones?You don't. Only the ones that are passed to a revoke API (e.g., logging out or the system automatically detecting fraudulent behaviours).
So there is no need to keep the old ones to block them cuz they don't have access anywayI'm arguing for storing less data. A blacklist will only store *revoked * unexpired refresh tokens. A white list will store all unrevoked unexpired refresh tokens. There will (most likely) be more unrevoked tokens than revoked tokens.
76 replies
TTCTheo's Typesafe Cult
•Created by Jimmy Page on 12/27/2024 in #questions
JWT with long-lived Refresh Tokens
If the refresh token expires, it's up to the client to remove it from its local state, which it should be able to do because the expiration is stated in the token. If it tries to send an expired refresh token to the server, the server will send back an error.
76 replies
TTCTheo's Typesafe Cult
•Created by Jimmy Page on 12/27/2024 in #questions
JWT with long-lived Refresh Tokens
You're right that you have to check the user table for every refresh but you'd do the same thing *regardless * if you're using a whitelist or blacklist.
In a whitelist:
1. User sends in refresh token to the refresh API
2. Server checks to see if the refresh token is in the whitelist
3. If it is, it pulls data from the user table to update claims
In a blacklist:
1. User sends in refresh token to the refresh API
2. Server checks to see if the refresh token is not in the blacklist
3. If it is not, it pulls data from the user table to update claims
The only difference is that we're looking for a match in the whitelist and looking for a miss in the blacklist.
In this case, the whitelist will still contain more data with the same number of calls to the DB. Since the user can have multiple refresh tokens (logged in to multiple devices), you'll need to store your whitelist separate from the user table.
76 replies
TTCTheo's Typesafe Cult
•Created by Jimmy Page on 12/27/2024 in #questions
JWT with long-lived Refresh Tokens
The expiration of the tokens is self-contained inside of the token itself, so that shouldn't be an issue
76 replies
TTCTheo's Typesafe Cult
•Created by Jimmy Page on 12/27/2024 in #questions
JWT with long-lived Refresh Tokens
you have to look up in the db when refreshing tokens, or you wont get updated context (updated roles and etc) in jwt token.Oooooh this is interesting. You're right.
76 replies
TTCTheo's Typesafe Cult
•Created by Jimmy Page on 12/27/2024 in #questions
JWT with long-lived Refresh Tokens
with black list you have to look up in black list AND in user/token table with each requestFrom what I understand, you don't do this. JWTs are self-contained. A user/token table would be a session-based approach, not JWT.
the question, what will happen if user will generate new refresh token? do you add old refresh token in black list?You do not add the old refresh tokens to the black list because this implies that they can only sign in with one device at a time. You'd only add them to the blacklist when the revoke API is invoked (like during logout).
76 replies
TTCTheo's Typesafe Cult
•Created by Jimmy Page on 12/27/2024 in #questions
JWT with long-lived Refresh Tokens
Actually, no. I still think the blacklist makes more sense here.
Here's an example. You have 1,000 users. 500 of these users sign in with only one device and need only 1 refresh token. The other 500 users sign in with two devices and need 2 refresh tokens.
With a whitelist, you're storing 1,500 tokens.
With a blacklist, you're storing 0 tokens.
Let's say 250 of these tokens leak and the system automatically revokes these refresh tokens.
The whitelist will now store 1,250 tokens.
The blacklist will store 250 tokens.
As the number of users increase, and the number of logins are invoked, the amount of tokens you need to store in the whitelist also increases. This makes it much more stateful on the server-side, which goes against the nature of JWT.
A blacklist could theoretically outgrow the whitelist if someone's able to leak a massive amount of tokens. In the average case, though, the whitelist will be larger.
76 replies
TTCTheo's Typesafe Cult
•Created by Jimmy Page on 12/27/2024 in #questions
JWT with long-lived Refresh Tokens
So more of a whitelist than a blacklist for refresh tokens
76 replies
TTCTheo's Typesafe Cult
•Created by Jimmy Page on 12/27/2024 in #questions
JWT with long-lived Refresh Tokens
Hmmm yeah, I see where you're coming from
76 replies
TTCTheo's Typesafe Cult
•Created by Jimmy Page on 12/27/2024 in #questions
JWT with long-lived Refresh Tokens
I guess a refresh token being a session token could be more effective, though
76 replies
TTCTheo's Typesafe Cult
•Created by Jimmy Page on 12/27/2024 in #questions
JWT with long-lived Refresh Tokens
From my understanding, yes, since it's a self-contained JWT. If it was a session token, then you wouldn't have to.
76 replies
TTCTheo's Typesafe Cult
•Created by Jimmy Page on 12/27/2024 in #questions
JWT with long-lived Refresh Tokens
But this can also be accomplished with a blacklist, which will hold less data than an exhaustive list of all refresh tokens
76 replies
TTCTheo's Typesafe Cult
•Created by Jimmy Page on 12/27/2024 in #questions
JWT with long-lived Refresh Tokens
Do you have any specific recommendations for resources?
76 replies
TTCTheo's Typesafe Cult
•Created by Jimmy Page on 12/27/2024 in #questions
JWT with long-lived Refresh Tokens
Why would you store all refresh tokens in a database? Wouldn't they also be JWT, and therefore self-contained? Storing a blacklist would be much more efficient from a scale POV, no? Regardless, it should have the same end result.
you do not allow a user to delete account without additional step of security, at minimum you require a password.Sure, this was just a general example. There are other ways that an attacker can cause damage in a short timeframe.
76 replies
TTCTheo's Typesafe Cult
•Created by Jimmy Page on 12/27/2024 in #questions
JWT with long-lived Refresh Tokens
Oh, are you talking about access tokens? I was responding to Ahmed's question about refresh tokens.
In the context of access tokens:
it is practically impossible to cause any real harm to userI don't know if I quite agree with this. Even if the attacker has 5 minutes, if they come in with a plan of which APIs to invoke, it could cause serious harm. For example, let's say they invoke an API to delete the user's account. That can be done pretty easily within the lifespan of the access token. That's a pretty simple example, but I'm sure there are far more possibilities that a well thought-out attack could produce in the lifespan of an access token.
have any time to receive a report and add to deny list access tokenThis is where a revoke API can come in handy. If you know that your tokens have been stolen, or if the system is able to automatically detect malicious actors, triggering a revoke API could automatically place the refresh and access tokens into blacklists. Of course, this means that you're going to need to keep a reference of all the non-expired access tokens in order to know which access tokens to place into the blacklist, adding more state - but this state wouldn't be used for auth, just for revocation purposes, so it should be fine.
76 replies
TTCTheo's Typesafe Cult
•Created by Jimmy Page on 12/27/2024 in #questions
JWT with long-lived Refresh Tokens
Why wouldn't you blacklist stolen tokens? In terms of the refresh token, it'd have the exact same result as logging out and banning. In all three cases, adding it to the blacklist would prevent it from making new access tokens.
76 replies
TTCTheo's Typesafe Cult
•Created by ROBLOX on 12/31/2024 in #questions
Every of my files are deleted
Why was I pinged lol
8 replies
TTCTheo's Typesafe Cult
•Created by ROBLOX on 12/31/2024 in #questions
Every of my files are deleted
???
8 replies
TTCTheo's Typesafe Cult
•Created by Jimmy Page on 12/27/2024 in #questions
JWT with long-lived Refresh Tokens
That's what the blacklist is for. If they steal your refresh token, you add it to the blacklist and it can no longer generate access tokens.
76 replies
TTCTheo's Typesafe Cult
•Created by Jimmy Page on 12/27/2024 in #questions
JWT with long-lived Refresh Tokens
Oh, I haven't even considered using an in-memory blacklist for access tokens. That makes a lot of sense to me. Another bandaid on top to increase security for a slight performance hit.
76 replies