5 ms·

> maintain a table of valid JWTs and expire them when the user logs out Wouldn't you just need a list of logged-out JWTs? And maintain entries until the JWT wo

by Rapzid 5y ago

> maintain a table of valid JWTs and expire them when the user logs out Wouldn't you just need a list of logged-out JWTs? And maintain entries until the JWT would have expired?. And that's if you really cared. Some people would be fine with the client and server participating in the log out and a low-ish JWT expiry.

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.
xyzzy123 5y ago
Agree, a lot of webapps can just ignore. Suppose you have a 10 min refresh time. Logout just deletes the client-side state and in 10 minutes the user will be "hard" logged out since their token hasn't been refreshed. Similar security to "abandoned session" which is of course what a very large % of users do instead of "logging out". There is risk of cloned session, but there's no law saying non-banking apps have to care. This has the nice property that if you're forced to, adding a cache to store invalidated tokens with a ttl of 10 minutes is an incremental enhancement.
hobofan 5y ago
You can "just" use a per-user "generation" key, which invalidates all keys when incremented server-side. The list can generally be mainted by polling every few seconds or via a websocket if you need the fastest possible expiry. Since most JWT libraries allow you to customize the validation function it's often pretty trivial to add, and overall comes only with a small memory penalty.

by Rapzid 5y ago

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.

xyzzy123 5y ago

Agree, a lot of webapps can just ignore. Suppose you have a 10 min refresh time. Logout just deletes the client-side state and in 10 minutes the user will be "hard" logged out since their token hasn't been refreshed. Similar security to "abandoned session" which is of course what a very large % of users do instead of "logging out". There is risk of cloned session, but there's no law saying non-banking apps have to care. This has the nice property that if you're forced to, adding a cache to store invalidated tokens with a ttl of 10 minutes is an incremental enhancement.

hobofan 5y ago

You can "just" use a per-user "generation" key, which invalidates all keys when incremented server-side. The list can generally be mainted by polling every few seconds or via a websocket if you need the fastest possible expiry. Since most JWT libraries allow you to customize the validation function it's often pretty trivial to add, and overall comes only with a small memory penalty.