The way we do it is with a long lived JWT (LLJWT) and short lived jwt (SLJWT). Our LLJWT lasts for a long time (think years) and is only able to to request a SLJWT, it alone has no abilities. Inside the LLJWT we store a UUID that we also store in the DB. The SLJWT is only valid for 1hr (we are testing on bringing that down to like 10min or so) and when it expires you have to use the LLJWT to request a new SLJWT. If at anytime we determine that there is abuse going on or someone wants to "remotely sign out" of a device they can invalidate the LLJWT and the next time it is used to request a new SLJWT it will be rejected.

If you need to access the DB to check if you can emit a new SLJWT, what's the point of the LLJWT? Why not just store that UUID by itself?

The SLJWT does seem useful, but 1h seems too much; if I fear someone might be (for example) accessing my email account using a stolen or hijacked device, they can do plenty of damage in that time. Do you make it clear to the user that their request for a remote sign out might take that long to be applied?

> If you need to access the DB to check if you can emit a new SLJWT, what's the point of the LLJWT?

It doesn't have to hit the DB, it could hit memcache or similar caching layer. It also means we could separate this table out from our main DB. We have done neither because it hasn't been an issue (performance-wise) yet.

> Why not just store that UUID by itself?

We could do that, our thought process was that we wanted everything to be a JWT and we liked the ability to, given a JWT, know who it was issued to, when it was issues, and when it expires, all without going to the DB.

> The SLJWT does seem useful, but 1h seems too much; if I fear someone might be (for example) accessing my email account using a stolen or hijacked device, they can do plenty of damage in that time. Do you make it clear to the user that their request for a remote sign out might take that long to be applied?

Totally agree on 1hr being too long and that is why we are planning on lowering it. We have technical reasons (legacy apps that we are trying to get updated) that will not work with lower than 1 hour (I won't bore people here with the details and there are workarounds but we haven't implemented them yet)

Right, but then you just added state and re-invented sessions, in a round-about way.

True, but it was what we decided was the best way forward with web and mobile app users to standardize how we manage authentication. Does it share characteristics with sessions? Yes and we are ok with that.

Edit: One more point, we also like how JWT's are language agnostic so that we can jump between languages very easily if needed and still use the exact same concepts. Sharing sessions between, say, Java and PHP is not something that is simple/fun/easy to do. JWT's are also easier for us to reason around with, maybe it's just me or my team but I see them as more finite than sessions.

In the past, I've compared the "iat" (issued at) value with a column in the users table called "invalidate_tokens_before". If I need to invalidate tokens for a user (for my use case, it would always be all tokens for a user at once), I just touch that timestamp column. True, it still required a db lookup (one that happens anyway), but I found that easier to manage than storing and managing session tokens.

Doesn't the author cover this in their rebuttal (http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo...), "Your blacklisting/revocation server goes down, now what?".

Everything from there goes to "Congratulations! You've just re-invented sessions (only with a less battle-tested implementation) and gained nothing in the process"

(Sarcasm is from the author's post, not mine!)

I don’t think of JWT as a replacement for db lookups or storage, but they do provide a convenience in not having to store and manage all sessions in the database[1]. I’ve done it both ways, and as long as you’re careful about a few of the potential security issues with JWT (solve it once, put it in a reusable module), it actually does save a considerable amount of code and complexity on the server side.

Also, in my case, "your blacklisting/revocation server goes down" means the whole application is down anyway, so that's kind of a moot point.

You may disagree, and there are valid reasons to avoid JWT. I'm just saying that under the right circumstances, it can be useful.

[1] The author claims that JWT isn't any easier, but then later says things like "Expiration can be implemented server-side just as well, and many implementations do". That's true, but it is something extra you have to implement yourself, i.e., not easier (for that feature at least).

The author is pretty clearly comparing using jwts with using some framework provided session solution, not having you implement sessions from scratch.

So just use a session library with expiration implemented, don’t take one without and add it on yourself.

Again, I’m not arguing that traditional sessions are bad and JWT is categorically good. Of course, if everything is already implemented for you[1], then ease-of-use is less of an issue, but there are valid use cases where JWT makes sense (it isn’t categorically “bad” as the author tries to show).

For some of my particular use cases[2], I happen to prefer the JWT approach (despite all the points given in the article, and after auditing the libraries used). For others, I definitely prefer traditional session tokens.

[1] Just because it’s been implemented by someone else, the complexity of that code still falls on you - especially so with something as critical as authentication. It’s not automatically “easy” because someone else implemented it; I’ve seen some pretty terrible security issues in both JWT libraries (e.g., insecure defaults) and framework-provided session management libraries.

[2] Guess what? If you have tens or hundreds of millions of users, managing sessions and expiration can be a bit of a pain. Example: to keep things performant, you'll want to periodically clean up your session store (rather than just invalidating at lookup). Congratulations - now you have a background worker and the complexities of dealing with that at scale. Point is, even with nice framework-provided libraries, managing session tokens on the server can add considerable complexity.

> there are valid uses cases where JWT makes sense (it isn’t categorically “bad” as the author tries to show).

The author does sound negative, but doesn't claim JWTs are categorically bad; he actually mentions cases where JWTs are useful: when they are used as single-use tokens. The author claims JWTs as sessions are too problematic to be useful.

> I’ve seen some pretty terrible security issues in both JWT and framework-provided session management libraries.

It seems to me the author is arguing JWTs (used as sessions) are more error prone and less battle tested than traditional session management. So if you've seen terrible security issues...

The "battle-tested" argument is becoming less and less obvious. As for being error-prone, I've seen a lot of people set up their session cookies incorrectly/insecurely when using traditional session tokens (and framework-provided authentication libraries), so I'd guess the two approaches are about on equal ground in the "error-prone" department.

Yes, the battle-tested argument becomes moot when enough time passes and there's enough adoption. This doesn't make the original argument invalid, though -- just unheeded! ;) It seems we software devs are doomed to reinvent the wheel, again, and again, and again.

As for session cookies: like the author says, cookies are a storage medium and orthogonal to the issue. You can have all the problems of JWTs in addition to all the problems of cookies.

Exactly! Because if you're implementing everything from scratch, you'd have to check the JWT's expiration yourself... it won't automatically expire by itself otherwise.

And how is that better than using sessions in the first place? What is your gain?