4 ms·

They can be revoked. Our JWTs have an ID in them. We have a revoked table. If the ID is in the revoked table, the JWT is invalid. It requires a DB hit but i

They can be revoked. Our JWTs have an ID in them. We have a revoked table. If the ID is in the revoked table, the JWT is invalid. It requires a DB hit but it is worth it for the ability to revoke them.

michaelchisari 9y ago
What advantage does this have over a session token/table? If you have to hit the db every time the JWT is referred to for an operation in order to prevent post-revocation activity, what advantage does the JWT provide?
- Posibyte 9y ago
  We keep our ID blacklist in something like Redis. For how rarely we need to add clients to it, the switch to simple-state JWTs has made noticeable improvements to the speed of our API, especially during higher usage times where our Postgres DB bogs down a bit. So I'd say the advantage really varies by where you're coming from.
  - ves 9y ago
    You could even switch what you have in redis to a bloom filter if the space of revocation tokens gets large (which it shouldn't). You don't need to support a database online if you're just checking for membership in a small finite set.
    - politician 9y ago
      Exactly, the database solution is overkill for tokens that are revoked prior to their expiration.
  - rhinoceraptor 9y ago
    You also just do it in Varnish/Nginx/etc and stick that in front of the application server entirely.
ezekg 9y ago
That's my whole point. If you're doing that, you might as well not use JWTs seeing as that defeats the entire purpose of using a stateless token that doesn't require DB hits.
- deathanatos 9y ago
  You can cache the table — which is usually empty — in the places where you need to validate a token to not require the DB lookup. You can also push changes in the revocation list to those places as well. Or, you can just have the DB lookup, but then cache it for 5 or 10 minutes: revocation will take that long to take effect, but most authentication verifications will still be very cheap and not require a lookup. JWTs allow it to be stateless, or some tradeoff along it appropriate to your needs. Having the client pass an ID to a database row means you can never get that behavior, as you always need to look up that row from the DB.
ademarre 9y ago
In addition to single token revocation, you can use the account epoch approach (at least that's what I call it): Store an "epoch" date in the database for each account. Tokens issued for that subject are considered invalid if they were issued before the epoch. This allows you to do mass token revocation (e.g. sign out all active sessions) without knowing the IDs of the tokens that have been issued.
- pjwal 9y ago
  This is the approach I take. The subject should always be queried, so just use a field on that subject for the purpose of killing current sessions.

michaelchisari 9y ago

What advantage does this have over a session token/table? If you have to hit the db every time the JWT is referred to for an operation in order to prevent post-revocation activity, what advantage does the JWT provide?

Posibyte 9y ago
We keep our ID blacklist in something like Redis. For how rarely we need to add clients to it, the switch to simple-state JWTs has made noticeable improvements to the speed of our API, especially during higher usage times where our Postgres DB bogs down a bit. So I'd say the advantage really varies by where you're coming from.
- ves 9y ago
  You could even switch what you have in redis to a bloom filter if the space of revocation tokens gets large (which it shouldn't). You don't need to support a database online if you're just checking for membership in a small finite set.
  - politician 9y ago
    Exactly, the database solution is overkill for tokens that are revoked prior to their expiration.
- rhinoceraptor 9y ago
  You also just do it in Varnish/Nginx/etc and stick that in front of the application server entirely.

ezekg 9y ago

That's my whole point. If you're doing that, you might as well not use JWTs seeing as that defeats the entire purpose of using a stateless token that doesn't require DB hits.

deathanatos 9y ago
You can cache the table — which is usually empty — in the places where you need to validate a token to not require the DB lookup. You can also push changes in the revocation list to those places as well. Or, you can just have the DB lookup, but then cache it for 5 or 10 minutes: revocation will take that long to take effect, but most authentication verifications will still be very cheap and not require a lookup. JWTs allow it to be stateless, or some tradeoff along it appropriate to your needs. Having the client pass an ID to a database row means you can never get that behavior, as you always need to look up that row from the DB.

ademarre 9y ago

In addition to single token revocation, you can use the account epoch approach (at least that's what I call it): Store an "epoch" date in the database for each account. Tokens issued for that subject are considered invalid if they were issued before the epoch. This allows you to do mass token revocation (e.g. sign out all active sessions) without knowing the IDs of the tokens that have been issued.

pjwal 9y ago
This is the approach I take. The subject should always be queried, so just use a field on that subject for the purpose of killing current sessions.