4 ms·

You can implement sign out everywhere by setting a reauth flag on the user in the database. You lose the "completely stateless" aspect that JWT claims to provid

You can implement sign out everywhere by setting a reauth flag on the user in the database. You lose the "completely stateless" aspect that JWT claims to provide, but it's a small trade-off for tighter security.

nneonneo 10y ago
If the user reauthenticates and you unset the reauth flag, wouldn't their previous sessions (e.g. tokens held by an attacker) suddenly become valid again? How would you prevent such an attack?
- inopinatus 10y ago
  You wouldn't use a boolean flag. I suggest setting a validity timestamp for the user, and reject any token that was issued-at any earlier time. (This isn't a perfect scheme since a compromised issuer could have been induced to send post-dated tokens. If your need for global logout was to invalidate tokens issued by a compromised issuer, you'll need to blacklist keys as well)
tszming 10y ago
Effectively now you are using database as your session storage?
- dexterdog 10y ago
  But you're not storing the session there, just the key/token so you can change it. The session payload is still completely in the JSON body maintained by the client and sent with each request.
  - jeremyjh 10y ago
    What difference does that make? Once you commit to this you have to do a database lookup for every request. Why not keep the session data there?
    - dexterdog 10y ago
      You only have to validate the token. It doesn't have to be a database-type medium because you're not writing very often in fact all you're really doing is making sure the token is not invalid. The session data could be changing on every request which would be at least one write on every request. With this system you are only writing to the central medium on a session creation or a session invalidation.
      - bigonlogn 10y ago
        This is not entirely true. Since we talking about implementing stateful sessions, you could receive a valid token (stolen, out otherwise) after the user has logged out. You are correct that the lookup doesn't have to be via the database. You could implement a caching system where the cache is invalidated when the user logs out and requires reauthentication. This is the notion of the session. By definition they cannot be stateless. Stateless authentication is inherently (slightly) less secure than sessions. I think of a blind librarian who gives out keys to the library. Whoever has a key has access. You can put limitations on the timeframe someone has access to the library, but that's it. If your key gets stolen, the blind librarian can't help you as there is no way for him to tell if it's really you.

nneonneo 10y ago

If the user reauthenticates and you unset the reauth flag, wouldn't their previous sessions (e.g. tokens held by an attacker) suddenly become valid again? How would you prevent such an attack?

inopinatus 10y ago
You wouldn't use a boolean flag. I suggest setting a validity timestamp for the user, and reject any token that was issued-at any earlier time. (This isn't a perfect scheme since a compromised issuer could have been induced to send post-dated tokens. If your need for global logout was to invalidate tokens issued by a compromised issuer, you'll need to blacklist keys as well)

tszming 10y ago

Effectively now you are using database as your session storage?

dexterdog 10y ago
But you're not storing the session there, just the key/token so you can change it. The session payload is still completely in the JSON body maintained by the client and sent with each request.
- jeremyjh 10y ago
  What difference does that make? Once you commit to this you have to do a database lookup for every request. Why not keep the session data there?
  - dexterdog 10y ago
    You only have to validate the token. It doesn't have to be a database-type medium because you're not writing very often in fact all you're really doing is making sure the token is not invalid. The session data could be changing on every request which would be at least one write on every request. With this system you are only writing to the central medium on a session creation or a session invalidation.
    - bigonlogn 10y ago
      This is not entirely true. Since we talking about implementing stateful sessions, you could receive a valid token (stolen, out otherwise) after the user has logged out. You are correct that the lookup doesn't have to be via the database. You could implement a caching system where the cache is invalidated when the user logs out and requires reauthentication. This is the notion of the session. By definition they cannot be stateless. Stateless authentication is inherently (slightly) less secure than sessions. I think of a blind librarian who gives out keys to the library. Whoever has a key has access. You can put limitations on the timeframe someone has access to the library, but that's it. If your key gets stolen, the blind librarian can't help you as there is no way for him to tell if it's really you.