> 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.
I did not know that encryption had made it in the JWT spec. My comment was supposed to convey surprise, not some sort of snark or sarcasm. I read the spec after the OP comment and learned something new today.
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.
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.