6 ms·

I think storing JWTs might make sense for some advanced scenarios where you have multiple services with varying security requirements but when you store JWTs, y

I think storing JWTs might make sense for some advanced scenarios where you have multiple services with varying security requirements but when you store JWTs, you lose a lot of the benefits of having a stateless token which doesn't require a database lookup. A possible alternative is to just make the JWT expiry very short; like one hour; then you don't really need to explicitly invalidate the token. With a real time bidirectional transport like WebSockets, you can make the JWT expiry even shorter; like 10 minutes and you can auto refresh it by pushing a replacement token to clients every 8 minutes or so. If the expiry is so short, you don't need the ability to invalidate tokens. Getting your laptop stolen while you are logged into a service which relies on JWT is like getting your credit card stolen; it will probably take at least 10 minutes for you call your bank to disable it.

deleted 8y ago
[deleted]
groestl 8y ago
An hour could be much much too long, depending on what service you are protecting. It's long enough that even assuming that token theft is a non-stealthy operation, and the user reacts immediately, the attacker has a lot of time to execute his attack. For things like Facebook, this could include slowly scaping all user data and spreading the infection vector to other users. As for websockets: session integrity is handled by TLS, and invalidation can be handled by closing the TCP connection. Authentication needs to happen only once, on connect.
- jondubois 8y ago
  Storing JWTs in a store or DB is difficult because you need to manage them and that means accounting for all possible edge cases. You can't always detect when a WebSocket/TCP connection has closed from the back end. For example, if your WebSocket server crashes suddenly, all active JWTs that you keep in your external data store will be orphaned and they won't get cleaned up until you run a separate cron job (which adds a lot of complexity). Storing JWTs in a hashmap in memory is also not ideal if you have multiple processes/servers because it doesn't account for WebSocket lost connection and reconnection edge cases; the client could reconnect to a different server/process than before.

deleted 8y ago

[deleted]

groestl 8y ago

An hour could be much much too long, depending on what service you are protecting. It's long enough that even assuming that token theft is a non-stealthy operation, and the user reacts immediately, the attacker has a lot of time to execute his attack. For things like Facebook, this could include slowly scaping all user data and spreading the infection vector to other users. As for websockets: session integrity is handled by TLS, and invalidation can be handled by closing the TCP connection. Authentication needs to happen only once, on connect.

jondubois 8y ago
Storing JWTs in a store or DB is difficult because you need to manage them and that means accounting for all possible edge cases. You can't always detect when a WebSocket/TCP connection has closed from the back end. For example, if your WebSocket server crashes suddenly, all active JWTs that you keep in your external data store will be orphaned and they won't get cleaned up until you run a separate cron job (which adds a lot of complexity). Storing JWTs in a hashmap in memory is also not ideal if you have multiple processes/servers because it doesn't account for WebSocket lost connection and reconnection edge cases; the client could reconnect to a different server/process than before.