What's the point of having a token if you need to check it with a database on every request?

Instead of `SELECT isValid from tokens where token="<TOKEN>"`, why not `SELECT user from sessions where session="<COOKIE-SESSION>"`?

You don't store the token in the database, you put it in a channel that deploys with your app and can up updated as needed. That can be a flat file shipped with production, or if a production push is too costly, set some other way.

Changing the static token causes all JWT token verifications to fail (since the token is stored in the JWT),so requires each user re-auth on the next request. It's a manual fail-safe to invalidate stored sessions.

This, of course can spike load considerably in the period immediately after, so if that's a problem, you can always use multiple tokens based on some criteria, such as one matching the first letter of the username, or the user id mod some value, so split your user into N chunks that each have their own invalidation token, so you only have to invalidate the sessions of 1/N users.

>>Changing the static token causes all JWT token verifications to fail (since the token is stored in the JWT),so requires each user re-auth on the next request.

So if a single user's token gets compromised, you force ALL users to log in again?

No, you force the JWT to be verified against the DB, which might be as simple as checking if the JWT creation time is older than the password update time in the DB, and if so, force only those users to log in.

All the token does is force some extra level of scrutiny. It doesn't mean the JWT has to be invalidated,but it does give you the ability to selectively invalidate specific ones for the cost of extra DB load once for all affected users.

I see. Thank you for clarifying. :)

Anyway, I'm still not convinced because when it comes to security I feel like it's a better idea to walk the well-trodden path, rather than invent new and exciting mechanisms. JWTs are useful for other stuff, but using them for security requires increasing back-end complexity quite a bit.

Sure, I'm not making a case JWT should be used, just that in the cases where the benefits it provides can yield real value (e.g. high capacity secured API with good caching infrastructure behind it), there are mitigations that might help offset the downsides.

Exactly, the moment you add statefulness you've basically reinvented session authentication.

There are a lot of problems with storing cookies when the front end and back end are hosted on different domains though. That is the main reason why people use JWTs with SPA apps, because otherwise it wouldn't really be possible to serve the front end from a CDN. Most people using JWTs aren't using them because they're stateless, but rather because it's the only way to solve the problem.

Why are checking against the DB here? Parent said a constant. You'd just check the constant value within the JWT vs the constant on the backend, and update the backend constant to invalidate.

(Correct me if I misunderstand you)

If you check against a single constant in the backend, are you invalidating all JWTs for all users whenever you want to invalidate only one? Even if you keep a blacklist of invalidated JWTs, how do you keep it up to date? How do you distribute it? What happens if the blacklist becomes unavailable for whatever reasons?

With jwt you have a standarized way to get the data on the client side for example.

Doesn't the author address this in their "Why your solution doesn't work" flowchart? Everything ends up a reinvention of traditional sessions, only with a less battle-tested implementation.

So you're saying you can have sane sessions as long as you have some server-side storage? :-)

Yes, of course, jwt can facilitate that. Using it as a replacement is not good, i agree.

But what value is it adding over ordinary 'bearer token' sessions in that case?

When you aren't invalidating tokens your app server can serve all static but restricted content without checking with the DB.

Or, implement a "master token" scheme: have a long-lived master token, which is used only for generating short-lived (e.g. 5 min) tokens that are actually used for authentication/authorization at the API endpoint.

User gets banned or privileges revoked? Fine, revoke the master token on the authentication server and after 5 minutes at the latest, the user is locked out as he cannot get new valid short-lived tokens.

Sessions aren't difficult - as long as you stick to one language and environment (e.g. PHP). But as soon as you throw in for example Java to communicate with a SAP backend (as an online-shop system might need to), nodejs for a "support/sales chat" system and whatever, a JWT scheme is easier to implement.

> Fine, revoke the master token

This is exactly the ability which JWT lacks.

You can, of course, combine a session ID (checked against a DB) with a short-lived token (stateless, with expiration time encoded). This will allow to only check the session against a DB if, say, more than 30 seconds has passed since the previous check. It helps with spiky traffic, and still allows to invalidate a session soon enough for practical reasons.

And this reduces complexity of all backend systems, as they only have to deal with one mechanism for authentication and authorization.

>> Fine, revoke the master token on the authentication server and after 5 minutes at the latest

That might be fine for a lot of use cases. But anything that can steal money using that token and 5 minutes is a very long time indeed.

    But anything that can steal money using that token and 5 minutes is a very long time indeed.

Then implement a check for the token in destructive operations. Should keep the performance impact pretty low.

With this method isn't the downside that you have to invalidate all tokens, and not just the attacker's tokens?

which isn't bad because all the processing is done client side anyway.

> which isn't bad because all the processing is done client side anyway.

I believe people are downvoting you because you may have overlooked the processing that must happen on the server to encode the token in the first place.

How do you encode it in such a way that you can invalidate individual tokens? How do you distribute that information among your services?

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?

In which case you wouldn't use JWT tokens at all...