9 ms·

This skips over one other big way that I’ve always seen JWT implementations fall over - sign out/session invalidation. A JWT has all the information for verify

This skips over one other big way that I’ve always seen JWT implementations fall over - sign out/session invalidation. A JWT has all the information for verifying its own lifetime contained within it, which is cool in that you don’t need to hit the DB to verify it… until you want to invalidate it before the embedded expiration is hit. Then you need to hit the database or some cache layer to verify that it isn’t invalidated, and now one of the biggest reasons to use it is gone. They do mention that for CRUD operations you’ll need to hit the DB anyways, which is in the same vein as this issue tho.

mrhands556 4y ago
Why not just have a lower TTL on your JWT?
- cercatrova 4y ago
  Then what's the point? Just use sessions at that point.
fastball 4y ago
Not really true if you use an access/refresh token system. The access token doesn't hit the DB for auth, the refresh token does. You have an access token with a lifetime of say somewhere between 1-10 minutes. If you want to invalidate a session, you just revoke the refresh token and any access tokens will be invalid soon after. In a system where a user is making 10+ requests in a minute, that can be well worth it to reduce stress on the DB without an appreciable loss in security.
- trinovantes 4y ago
  Cookie sessions are usually stored in fast caches like redis so the performance hit is negligible. Most people will never reach the performance ceiling of a beefy single redis instance so why bother complicating the system?
  - LanceH 4y ago
    Even when storing the cookies in a database like Postgres, they are fast enough because it's obviously indexed, and it's probably cached in many usage patterns. JWT is solving a non-problem for most people. Now, if you're talking machines talking to machines, all owned/operated by the same entity, go wild with JWT's if you want.
    - unqueued 4y ago
      > Even when storing the cookies in a database like Postgres, they are fast enough because it's obviously indexed, and it's probably cached in many usage patterns. If you scale up high enough, it does matter. But beyond that, it is also about decoupling the server serving the content and the user database. To give you an example, using a traditional session cookie model, whenever my server gets a request, it has to look up the associated session info, and then possibly join multiple tables to see if a specific user for that specific session is authorized to access that content. There are going to be many joins involved. Even with good caching, it will still be a more complex operation. Even if not computationally complex, it will be logically complex. But when using a JWT, my server actually does not need ANY db access. It merely needs to verify the cryptographic validity of the included JWT header, which uses no IO. After that, it can safely trust any user metadata included in the JWT. So, if a user has paid for access to all premium content after 2018, you would just include a field for that in your JWT payload. Done. It depends of course on how your business data models work of course. But you can often put enough information in your JWT to cut out a lot of account processing logic. > JWT is solving a non-problem for most people. I think people are cargo culting JWTs.
      - P5fRxh5kUvp2th 4y ago
        When people talk about caching user information, access is one of the things cached. That complicated joining happens exactly as often with sessions as it does with JWT's.
        unqueued 4y ago
- jtchang 4y ago
  How does this solve it? You still need to wait 1 minute.
  - fastball 4y ago
    What security context are we talking about where that 1 minute matters?
    - leodriesch 4y ago
      A person has accessed your account and you’ve noticed it via sign-in-email. You change your password. Attacker now still has 1-10 minutes to access your account.
- P5fRxh5kUvp2th 4y ago
  I have this rant about people creating problems for themselves. A perfect example is when SPA's were created, but it broke browser history. So we get a new standard with the ability to edit browser history. I feel like refresh/access tokens fall into the same vein. If you need that don't use JWT's. The choice of JWT is the problem here, refresh/access tokens are a workaround.
kylebyproxy 4y ago
I feel like this point gets overblown. Subscribing to an "invalidations" message queue seems pretty straightforward. What am I missing?
- eropple 4y ago
  An invalidations queue will fail open if the queue does not deliver. If you check a session token against a database and the database is down, you fail closed. There are systems at scales where you have to take that hit, but the overwhelming majority of people don't run them.
- foobiekr 4y ago
  How many do you retain?
  - hangonhn 4y ago
    Not that many since they only last 10 to 15 minutes so you can just set the TTL to that. Also, you only need to retain the “jti” of the token and not the entire token. So you can hold quite a lot of these jti of tokens even in memory which is what we do. And then after 15 minutes they are ejected from memory.
- capn_duck 4y ago
  Can you explain what this looks like? So each application that authenticates its requests using the jwt subscribes to a message queue and replicates the data in some database local to it? Then it checks that database each time a new request comes in?
  - monocasa 4y ago
    Depends on how many invalidations you see. Some systems can get away with a message queue with an in memory copy of whatever's still in TTL with a bloom filter in front to make for a really cheap check. If you have more invalidations than a simple library implementation can handle, you do a similar thing with a DB like Redis sitting off to the side.
parker_mountain 4y ago
> sign out/session invalidation I wrote it up in another comment, but basically: if you're using JWTs, and you have lots of services calling each other in a request (as you might with microservices), it's entirely appropriate to have a session check ("remote introspection") when you access sensitive information, such as PII. And, maybe, at the edge layer as well.

mrhands556 4y ago

Why not just have a lower TTL on your JWT?

cercatrova 4y ago
Then what's the point? Just use sessions at that point.

fastball 4y ago

Not really true if you use an access/refresh token system. The access token doesn't hit the DB for auth, the refresh token does. You have an access token with a lifetime of say somewhere between 1-10 minutes. If you want to invalidate a session, you just revoke the refresh token and any access tokens will be invalid soon after. In a system where a user is making 10+ requests in a minute, that can be well worth it to reduce stress on the DB without an appreciable loss in security.

trinovantes 4y ago
Cookie sessions are usually stored in fast caches like redis so the performance hit is negligible. Most people will never reach the performance ceiling of a beefy single redis instance so why bother complicating the system?
- LanceH 4y ago
  Even when storing the cookies in a database like Postgres, they are fast enough because it's obviously indexed, and it's probably cached in many usage patterns. JWT is solving a non-problem for most people. Now, if you're talking machines talking to machines, all owned/operated by the same entity, go wild with JWT's if you want.
  - unqueued 4y ago
    > Even when storing the cookies in a database like Postgres, they are fast enough because it's obviously indexed, and it's probably cached in many usage patterns. If you scale up high enough, it does matter. But beyond that, it is also about decoupling the server serving the content and the user database. To give you an example, using a traditional session cookie model, whenever my server gets a request, it has to look up the associated session info, and then possibly join multiple tables to see if a specific user for that specific session is authorized to access that content. There are going to be many joins involved. Even with good caching, it will still be a more complex operation. Even if not computationally complex, it will be logically complex. But when using a JWT, my server actually does not need ANY db access. It merely needs to verify the cryptographic validity of the included JWT header, which uses no IO. After that, it can safely trust any user metadata included in the JWT. So, if a user has paid for access to all premium content after 2018, you would just include a field for that in your JWT payload. Done. It depends of course on how your business data models work of course. But you can often put enough information in your JWT to cut out a lot of account processing logic. > JWT is solving a non-problem for most people. I think people are cargo culting JWTs.
    - P5fRxh5kUvp2th 4y ago
      When people talk about caching user information, access is one of the things cached. That complicated joining happens exactly as often with sessions as it does with JWT's.
      - unqueued 4y ago
jtchang 4y ago
How does this solve it? You still need to wait 1 minute.
- fastball 4y ago
  What security context are we talking about where that 1 minute matters?
  - leodriesch 4y ago
    A person has accessed your account and you’ve noticed it via sign-in-email. You change your password. Attacker now still has 1-10 minutes to access your account.
P5fRxh5kUvp2th 4y ago
I have this rant about people creating problems for themselves. A perfect example is when SPA's were created, but it broke browser history. So we get a new standard with the ability to edit browser history. I feel like refresh/access tokens fall into the same vein. If you need that don't use JWT's. The choice of JWT is the problem here, refresh/access tokens are a workaround.

kylebyproxy 4y ago

I feel like this point gets overblown. Subscribing to an "invalidations" message queue seems pretty straightforward. What am I missing?

eropple 4y ago
An invalidations queue will fail open if the queue does not deliver. If you check a session token against a database and the database is down, you fail closed. There are systems at scales where you have to take that hit, but the overwhelming majority of people don't run them.
foobiekr 4y ago
How many do you retain?
- hangonhn 4y ago
  Not that many since they only last 10 to 15 minutes so you can just set the TTL to that. Also, you only need to retain the “jti” of the token and not the entire token. So you can hold quite a lot of these jti of tokens even in memory which is what we do. And then after 15 minutes they are ejected from memory.
capn_duck 4y ago
Can you explain what this looks like? So each application that authenticates its requests using the jwt subscribes to a message queue and replicates the data in some database local to it? Then it checks that database each time a new request comes in?
- monocasa 4y ago
  Depends on how many invalidations you see. Some systems can get away with a message queue with an in memory copy of whatever's still in TTL with a bloom filter in front to make for a really cheap check. If you have more invalidations than a simple library implementation can handle, you do a similar thing with a DB like Redis sitting off to the side.

parker_mountain 4y ago

> sign out/session invalidation I wrote it up in another comment, but basically: if you're using JWTs, and you have lots of services calling each other in a request (as you might with microservices), it's entirely appropriate to have a session check ("remote introspection") when you access sensitive information, such as PII. And, maybe, at the edge layer as well.