[tuyiown]

Access revocation: sometimes it's critical to block access to an issued token, without trusting the client to comply with revocation, especially for malicious cases.

Enforcing this implies to implement access control on each (critical) request, giving little advantage to a self contained token compared to a pure stateful signed session token.

[vbezhenar]

With ordinary sessions you need to store all active sessions in server. Sessions might be long-lived, may be eternal.

With JWT you need to store forcibly terminated active sessions in server. Those sessions are short-lived. So basically it's empty map.

Another solution with token is to change server key and force all short lived sessions to reauthenticate. It is not very nice, but if that's an extremely rare scenario, it might be appropriate to get rid of checking each request while still supporting forcible logout.

[holtalanm]

Yeah, if you need that kind of control over token access, then im not certain a jwt is the right tool for the job. For most use-cases a short-lived jwt is fine, as it expires in a matter of minutes, or even seconds, depending on configuration.

[cmeacham98]

The ability to logout existing sessions (typically either via a manual user action or automatically upon changing/resetting their password) is a desirable feature in essentially all applications where user accounts can be compromised.

You can kind of fake this by using a short-lived JWT and constantly refreshing it, but this:

1. Massively increases server strain and bandwidth usage

2. Has problems with users less reliable connections (they'll be randomly logged out all the time)

3. Makes "Remember Me" style features impossible (unless you use a server-side store for that, which brings us back to it not being stateless)

Here's a good graph on why $method to make JWTs work for sessions is bad: http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo... (note: for some reason the website doesn't support HTTPS :( )

[holtalanm]

> 1. Massively increases server strain and bandwidth usage

A short-lived JWT that fits into an HTTP Header is not going to _massively_ increase your bandwidth usage. At most, you will end up with a single refresh request every few minutes as each short-lived JWT expires.

> 2. Has problems with users less reliable connections (they'll be randomly logged out all the time)

Usually if your request failed due to a bad connection, the client wouldn't be designed to automatically log out the user. That would be just terrible UX.

> 3. Makes "Remember Me" style features impossible (unless you use a server-side store for that, which brings us back to it not being stateless)

Incorrect. A short-lived JWT tied to a refresh token allows for a remember-me style feature by checking account access when issuing a new JWT token.

[endiangroup]

AD: I wrote a library that can deal with this for JWT https://github.com/endiangroup/compandauth

The skiny is that you place a copy of some monotonic counter inside every JWT you issue, you keep track of the counter server side and compare with each request's JWT copy + some delta (which is the equivalent of maximum number of concurrent sessions you wish the user to have).

[inshadows]

Set counter = 0 in DB. Put it into JWT. Increment the counter in DB to revoke the user. Compare counter in JWT < counter in DB. What's the problem?

[holtalanm]

then you're hitting the db on every request just to do auth.

if you _had_ to do that, I would put the counter into something like redis instead.

[inshadows]

Don't you need to hit the DB anyway to fetch authorization data like user role? Clearly you aren't going to store it in JWT or you face the issue with invalidation. But fine, cache it in Redis. Problem solved.

10 timeout to reply. o_O