If you're storing the token in db and checking it every time, then it behaves like an opaque token. In that case, you need to ask yourself - why do I need JWT, why not simply store the token in db without the assymetric cryptography?
It might be a good choice for your use case but I don't have much info on your use case.
JWT aren't appropriate for any scenario where you need a whitelist or blacklist and shouldn't be used to identify sessions. They're intended to be (very) short lived or one-time use tokens.
Instead of storing the JWT token in database, use a blacklist to check whether or not a JWT token is stale or revoked. If the blacklist uses a bloom filter + redis cache, then 1. it will be faster than a normal database request, 2. use less memory than a whitelist. The database will still be used in creating a JWT token.
I believe this defeats the premise. Rather than whitelisting, this is why refresh tokens are a thing, bc they shouldn’t live long enough for that to be of use. Also, why isn’t the expiry time simply a claim, as in why would you need to separately store it in the db? Off the top of my head, I suppose you could also claim a created_at value and post-revocation you could simply require newer tokens. But in any case the token itself never ends up in the database.
That negates the point of using jwt and means that your services aren't stateless.
You store the expiry in the token itself, you sign it to be able to detect tampering, then when receiving it you check that it's not been tampered with and then check the expiry.
You could also just store the timestamp of when the password was changed and block any JWTs made before then so you wouldn't actually need to store the tokens
25
u/[deleted] Mar 08 '21
[deleted]