> Now it's really hard to argue with architects / developers why cookie authentication / bearer token makes more sense than JWTs.
Because that's a nonsensical argument? JWT is just a token + validation. Nothing more. You can use JWTs in cookie authentication, you can use them as bearer tokens. The only thing JWTs are doing is carrying a payload and signing it.
Now, if you want to talk about Oath2 or OIDC then maybe there's a different argument to be had.
> Now, if you want to talk about Oath2 or OIDC then maybe there's a different argument to be had.
I imagine that is the main argument. People use JWT because it's standardized on the authentication protocol... The same authentication protocols that are horrible in many more ways than simply using a bad token format.
Yet everybody jumped into them when Google commanded.
JWTs aren't for transmitting sensitive data or encrypting things. JWTs are about having claims that can't be forged by the client.
So why would you put a JWT in a cookie? To give the end user a set of claims that they can't change, they can only read and give back to the server. Those claims can include things like user id, or session id, or whatever you might imagine.
Now, could you accomplish the same thing with an encrypted cookie? Absolutely. I'm not arguing about what you can or can't do with stuff. But rather again commenters saying "JWT is such and such and forces so and so". It's nothing but a signed set of claims.
stop being snarky, there are RFC's describing JWS and JWE, people just use the term JWT generically and let the context dictate what they're actually referring to.
Because cookies can be set to HttpOnly, making them inaccessible to JavaScript. They're also automatically included in all requests, so if you want to download a file that requires authentication, you don't have to do some convoluted JavaScript trickery to accomplish it. It can just be a regular link.
I feel like the people who bash JWTs have never actually built a real-life application using them. Yes, there are footguns. But they are dead-simple to mitigate, and they are far from the only footguns in the world of web applications.
Yes, you can't fully "log out" without a centralized database. But who cares? A JWT in an HttpOnly and Secure (requires HTTPS) cookie is very well locked-down. I'm not worried about an attacker being able to retrieve it, because if they can then the client is pretty well owned at that point and the attacker can do whatever they want.
I deal with applications that run multiple instances. To support that, it would require either an affinity cookie to "stick" the session to a single instance (which could go down at any time based on load) or a centralized session database. I don't like either of those options, so I use JWT cookies.
Have a B2B product where you'll have, maybe, someday, and I'm exaggerating here, X00,000 DAUs? Just set up cookie auth and track the sessions in Redis. Session revocation is super-super simple and you'll easily be able to handle any security vendor questionnaire asking how you lock out terminated accounts.
I agree. Not enough critical thinking was happening when I saw devs start adopting JWT without clearly stating why, other than "current best practices is to use JWT... end of discussion".
My concerns with JWT from early on is that the data stored in them was potentially stale. Front-end developers would always request fresh data at each interaction. Second, the JWTs were so long. We had to keep passing these long JWTs around.... mainly for testing stuff out, we had long lived tokens, especially in dev, so I think we passed them around to replicate API calls. So you felt how long they were.... and in my head I kept thinking about all this useless data being passed around taking up CPU/network/memory resources. So I would just remove JWT and replace the tokens with UUIDs. Everyone was happy about it, but they were confused as to why they were needed in the first place. I would just respond with, well when you find out let me know and I can add them back.
Issue tokens that have a reasonably short TTL - say, half an hour - and let clients use their refresh token to obtain a new token after that. On refresh requests, ask the database whether the refresh token has been invalidated, if it is, return 403 (bonus points for checking the expiration date first and delete expired and invalidated tokens from the invalid-list).
This reduces the necessary database roundtrips, while still supporting a logout flow.
I'm not the person you replied to, but in most implementations I've seen - they don't. Front end or app is politely asked to delete the token to simulate the user logging out, but the token isn't revoked in any meaningful fashion.
No additional checks are performed on the back-end to verify whether the token has been revoked as that would reintroduce a round trip to the database you're trying to avoid in the first place.
Well, when dealing with OIDC / OAuth you can bind the tokens to the user session or trigger back channel logouts.
But anyways its not really easy to tell an RP to stop using a token.
No one - OP included - is arguing that there are no good use cases at all. Just that most situations don't call for it, and you're better off with something less complex.
Because that's a nonsensical argument? JWT is just a token + validation. Nothing more. You can use JWTs in cookie authentication, you can use them as bearer tokens. The only thing JWTs are doing is carrying a payload and signing it.
Now, if you want to talk about Oath2 or OIDC then maybe there's a different argument to be had.