5 ms·

Can't you keep a whitelist/blacklist of tokens in a memory cache like redis/memcached and go from there? As far as I know that is the standard practice to inval

Can't you keep a whitelist/blacklist of tokens in a memory cache like redis/memcached and go from there? As far as I know that is the standard practice to invalidate non expired sessions tokens.

jaimehrubiks 4y ago
Yes but if each microservice needs to check a cache on each request, then why use jwt at all, you could just save a classic session (with random token) in that cache as well
- hunterb123 4y ago
  The redis cache with invalidated tokens will be much smaller than storing all sessions. And you can expire the invalidated keys faster (set the invalidated key expiration to the expiration of the JWT) Not many people revoke sessions, but a lot of people create sessions. Much more efficient to only store and check revocations. The rest can be stateless.
  - szastamasta 4y ago
    I don't think that biggest issue with central auth database is its size.
    - moduspol 4y ago
      It depends on your scale, but even at small scale, your central auth database is something that needs to be highly available because your whole system is down otherwise. Obviously the situation is the same when managing a token blacklist if you truly have a hard requirement that sessions be instantly invalidated at a specific point, but there's a good chance you don't. Maybe it's OK to presume signed tokens are still good for some amount of time if your blacklist server is unreachable, or maybe waiting until the JWT expires after 60 minutes is too long, but a one or two minute delay is acceptable. Or maybe you only check the blacklist for high-risk API requests. It's not ideal. Invalidation is definitely a weakness of JWTs, but there's still a lot of value in baseline statelessness.
- wdb 4y ago
  Why not let the API Gateway check it?
  - eagsalazar2 4y ago
    "Yes but then ... why use jwt at all, you could just save a classic session (with random token) in that cache as well". JWTs add complexity and have zero benefit. The author never said it can't be made to work, obviously it can. It's just completely pointless in most applications.
dementiapatent 4y ago
Yes, and there is even a JWT field to hold the unique identifier for that token - https://www.rfc-editor.org/rfc/rfc7519#section-4.1.7 https://www.rfc-editor.org/rfc/rfc7519#section-4.1.7 . Makes it easy to track issued tokens and revoke them too.
brunojppb 4y ago
But then you introduce a database-like dependency that potentially every micro service will need access to.
- themenomen 4y ago
  Yes, that comes with its own caveats
drinchev 4y ago
As explained in the article, if that's the case then you can't really trust the JWT anymore only for it's cryptographic signature and you rely on an internal store entry that makes the token valid / invalid. This makes no benefits as to bearer token or any random string that the server "knows" is a valid authenticated request via internal store, like a DB.
eli 4y ago
why not just use a session token at that point?
- hunterb123 4y ago
  Because you're only storing the invalidated tokens and you're only storing them for the length of the token's lifetime (expire the redis key when the JWT expires) So instead of storing all session tokens indefinitely, you only store invalidated tokens for a short period of time.
  - ravenstine 4y ago
    Since when were session tokens ever a bottleneck? That's a problem I've never heard of on any scale. Yet again, JWT seems to be trying to solve a non-problem. Session tokens don't even have to be stored indefinitely. If a user isn't active for a period of time (even 30 days let's say) then the session token can be removed. Or, if memory truly was a problem for session tokens (not sure why honestly), transition tokens to storage after x amount of time and bring them back into memory when the user is active again.
    - hunterb123 4y ago
      I simply explained the efficiency difference of the two setups. You're storing and checking a smaller subset when doing stateless + invalidation cache. Whether or not you need that memory optimization is up to you and your machines. Personally it's about the same effort to implement and I prefer stateless + simple redis cache for invalidations.
      - marcosdumay 4y ago
        Well, on the other hand, you will have to distribute that revocation list somehow, what does add some complexity to your code. If you are already distributing lists around your application servers (that impacts the format and top performance of the redis cache), then yes, it's quite simple.
rkagerer 4y ago
That's discussed in the article in the second paragraph under "Problems with JWT". If you're keeping a cache at each server node then you might as well just use bearer tokens.

Can't you keep a whitelist/blacklist of tokens in a memory cache like redis/memcached and go from there? As far as I know that is the standard practice to invalidate non expired sessions tokens.

jaimehrubiks 4y ago

Yes but if each microservice needs to check a cache on each request, then why use jwt at all, you could just save a classic session (with random token) in that cache as well

hunterb123 4y ago
The redis cache with invalidated tokens will be much smaller than storing all sessions. And you can expire the invalidated keys faster (set the invalidated key expiration to the expiration of the JWT) Not many people revoke sessions, but a lot of people create sessions. Much more efficient to only store and check revocations. The rest can be stateless.
- szastamasta 4y ago
  I don't think that biggest issue with central auth database is its size.
  - moduspol 4y ago
    It depends on your scale, but even at small scale, your central auth database is something that needs to be highly available because your whole system is down otherwise. Obviously the situation is the same when managing a token blacklist if you truly have a hard requirement that sessions be instantly invalidated at a specific point, but there's a good chance you don't. Maybe it's OK to presume signed tokens are still good for some amount of time if your blacklist server is unreachable, or maybe waiting until the JWT expires after 60 minutes is too long, but a one or two minute delay is acceptable. Or maybe you only check the blacklist for high-risk API requests. It's not ideal. Invalidation is definitely a weakness of JWTs, but there's still a lot of value in baseline statelessness.
wdb 4y ago
Why not let the API Gateway check it?
- eagsalazar2 4y ago
  "Yes but then ... why use jwt at all, you could just save a classic session (with random token) in that cache as well". JWTs add complexity and have zero benefit. The author never said it can't be made to work, obviously it can. It's just completely pointless in most applications.

dementiapatent 4y ago

Yes, and there is even a JWT field to hold the unique identifier for that token - https://www.rfc-editor.org/rfc/rfc7519#section-4.1.7 https://www.rfc-editor.org/rfc/rfc7519#section-4.1.7 . Makes it easy to track issued tokens and revoke them too.

brunojppb 4y ago

But then you introduce a database-like dependency that potentially every micro service will need access to.

themenomen 4y ago
Yes, that comes with its own caveats

drinchev 4y ago

As explained in the article, if that's the case then you can't really trust the JWT anymore only for it's cryptographic signature and you rely on an internal store entry that makes the token valid / invalid. This makes no benefits as to bearer token or any random string that the server "knows" is a valid authenticated request via internal store, like a DB.

eli 4y ago

why not just use a session token at that point?

hunterb123 4y ago
Because you're only storing the invalidated tokens and you're only storing them for the length of the token's lifetime (expire the redis key when the JWT expires) So instead of storing all session tokens indefinitely, you only store invalidated tokens for a short period of time.
- ravenstine 4y ago
  Since when were session tokens ever a bottleneck? That's a problem I've never heard of on any scale. Yet again, JWT seems to be trying to solve a non-problem. Session tokens don't even have to be stored indefinitely. If a user isn't active for a period of time (even 30 days let's say) then the session token can be removed. Or, if memory truly was a problem for session tokens (not sure why honestly), transition tokens to storage after x amount of time and bring them back into memory when the user is active again.
  - hunterb123 4y ago
    I simply explained the efficiency difference of the two setups. You're storing and checking a smaller subset when doing stateless + invalidation cache. Whether or not you need that memory optimization is up to you and your machines. Personally it's about the same effort to implement and I prefer stateless + simple redis cache for invalidations.
    - marcosdumay 4y ago
      Well, on the other hand, you will have to distribute that revocation list somehow, what does add some complexity to your code. If you are already distributing lists around your application servers (that impacts the format and top performance of the redis cache), then yes, it's quite simple.

rkagerer 4y ago

That's discussed in the article in the second paragraph under "Problems with JWT". If you're keeping a cache at each server node then you might as well just use bearer tokens.