4 ms·

> Wouldn't you just need a list of logged-out JWTs? Sure, but that's not a real improvement. It's still stateful since you need to check the list with every re

by rsj_hn 5y ago

> Wouldn't you just need a list of logged-out JWTs? Sure, but that's not a real improvement. It's still stateful since you need to check the list with every request, you can't just verify the signature. Changing the logic from "must be in this list" versus "must not be in this list" does not give you much -- maybe some performance gain, depending on the situation. > And that's if you really cared. Well, that's my point. Developers may not care, but from the point of view of a security auditor, it's a vulnerability in your auth system, so the GRC/Security people do care, even if Foo start up doesn't. At some point, if Foo is successful, they will face this issue and need to support real logout to get the certifications they need to do business or be in compliance.

ecnahc515 5y ago
JWTs expire, so you only need to maintain a list of invalidated JWTs that haven't expired yet. You get two short cuts, one that you only check for revoked tokens which aren't expired and have valid signatures. This can save a lot of DB queries given you usually have to check auth validity per request.
- lbriner 5y ago
  How does that help? You won't know which tokens should be considered expired in-advance, you still have to call the DB for every request to check. There won't be many that are called with expired tokens compared with people using the site constantly and always having valid tokens.
  - bobthebuilders 5y ago
    You don't need a DB. The same in memory stuff that supposedly works for fast session auth works here too.
  - ecnahc515 5y ago
    > You won't know which tokens should be considered expired in-advance, you still have to call the DB for every request to check You can verify the signature before calling the DB.
  - giaour 5y ago
    You can push a list of revoked tokens to each server (similar to how certificate revocation lists work with (m)TLS).
hn_throwaway_99 5y ago
> Changing the logic from "must be in this list" versus "must not be in this list" does not give you much -- maybe some performance gain, depending on the situation. As someone who implements this exact solution, it actually gives you a lot. If your JWTs have a relatively small timeout window (say N minutes), then that means the number of expired tokens you have to keep track of is usually very small (e.g. for everyone who clicks the logout button with a valid token you have to keep that token around for at most N minutes), and on many websites the average user never makes an explicit logout request. So that means that in many (most?) usage scenarios you can just replicate the list of recently expired tokens to your servers (easy with something like Redis) and then just check incoming requests against that in-memory list. Again, this isn't anything special or new, it is discussed in the article. This is very different from storying the list of every valid JWT, which will often times be much bigger than you can store in memory.
Franciscouzo 5y ago
You can use a bloom filter to check if a token has been revoked, and then do the query for false positives.

by rsj_hn 5y ago

ecnahc515 5y ago

JWTs expire, so you only need to maintain a list of invalidated JWTs that haven't expired yet. You get two short cuts, one that you only check for revoked tokens which aren't expired and have valid signatures. This can save a lot of DB queries given you usually have to check auth validity per request.

lbriner 5y ago
How does that help? You won't know which tokens should be considered expired in-advance, you still have to call the DB for every request to check. There won't be many that are called with expired tokens compared with people using the site constantly and always having valid tokens.
- bobthebuilders 5y ago
  You don't need a DB. The same in memory stuff that supposedly works for fast session auth works here too.
- ecnahc515 5y ago
  > You won't know which tokens should be considered expired in-advance, you still have to call the DB for every request to check You can verify the signature before calling the DB.
- giaour 5y ago
  You can push a list of revoked tokens to each server (similar to how certificate revocation lists work with (m)TLS).

hn_throwaway_99 5y ago

> Changing the logic from "must be in this list" versus "must not be in this list" does not give you much -- maybe some performance gain, depending on the situation. As someone who implements this exact solution, it actually gives you a lot. If your JWTs have a relatively small timeout window (say N minutes), then that means the number of expired tokens you have to keep track of is usually very small (e.g. for everyone who clicks the logout button with a valid token you have to keep that token around for at most N minutes), and on many websites the average user never makes an explicit logout request. So that means that in many (most?) usage scenarios you can just replicate the list of recently expired tokens to your servers (easy with something like Redis) and then just check incoming requests against that in-memory list. Again, this isn't anything special or new, it is discussed in the article. This is very different from storying the list of every valid JWT, which will often times be much bigger than you can store in memory.

Franciscouzo 5y ago

You can use a bloom filter to check if a token has been revoked, and then do the query for false positives.