So, what should one should use then?
However, It's insecure with a bad client, right?
Beacuse I was going to use http+JWT for microservices communication an internal network, would that be a problem? any tips on what to switch?
JSON Web Tokens should be avoided
31–40 of 304 posts
Re: JSON Web Tokens should be avoided
#32Earlier quoted context omitted.
Out of interest, do you check the authenticity and integrity of the JWT on the client side?
We provide an endpoint to check validity with the server, but haven't used it too often. Anything "reasonably sensitive" (or more) doesn't depend on anything like this client-side security. But, if you're just hiding an additional Delete button on a page based on claims, this comes in handy. (Edit: in one case, we've used asymmetric keys, i.e. public key so everyone can check integrity. This was a very different use-…
That's exactly what is useful for. Of course access to a resource is determined server-side; JWT simply allows you to adjust the UI to the permissions the user has without any additional calls. If the user changes the JWT he has client-side, he will just get a broken delete button (the server will reject a JWT that has been tampered with).
Re: JSON Web Tokens should be avoided
#33So, what should one should use then? However, It's insecure with a bad client, right? Beacuse I was going to use http+JWT for microservices communication an internal network, would that be a problem? any tips on what to switch?
JWT is fine. Just lock down the library you chose as much as possible (only accept one algorithm for instance).
Re: JSON Web Tokens should be avoided
#34"Just use cookies over HTTPS [instead of JWT]" is weird advice. I mean, JWT goes… inside… things like cookies. (or the Authorization header in APIs, of course)
Re: JSON Web Tokens should be avoided
#35Earlier quoted context omitted.
But they aren't. Nobody is suggesting to anybody to use NONE as the algorithm.
EDIT: the secondary spec describing the algorithms is at least clear on the use of none, I missed that at first: Implementations that support Unsecured JWSs MUST NOT accept such objects as valid unless the application specifies that it is acceptable for a specific object to not be integrity protected. Implementations MUST NOT accept Unsecured JWSs by default. https://www.rfc-editor.org/rfc/rfc7518.txt Still, my point…
I don't think the spec meant to read that you must allow the client to be able to forge tokens by accepting tokens issued by it without an algo or signature.
If you issue tokens with none, then you will have to accept them when clients send them back. This is obviously a very bad idea, but that's all th spec says. If the issuer chooses to be insecure, that is a valid choice.
If you issue tokens with a specific algo, and clients send them back with a different or none header, you know they have been forged.
The spec allows issuers to decide whether to use none, it doesn't say you must trust none tokens if you know you didn't issue them.
Re: JSON Web Tokens should be avoided
#36Oh my god! Outrage! Superlatives!
Come on. By all means, criticize flawed implementations containing bugs and security holes, but drop the attention-seeking behavior of screaming loudly about how an entire standard is [insert string of superlatives here related to "worthless" and "broken"]. If you're going to make such incredibly strong claims, your arguments had better be up to snuff.
With good implementations (plenty of which exist), and careful usage (via good coding and design habits), JWT is a fine standard and it can save a solid amount of time when constructing the security portions of a system.
Shouting about how something is 100% flawed and should be cast into the flames may get you plenty of views and outrage cred, but (thankfully) it doesn't say much about the veracity of your analysis.
Re: JSON Web Tokens should be avoided
#37Earlier quoted context omitted.
Session invalidation is possible though, by maintaining a (short) blacklist of tokens on the server. JSON Web Tokens can be given an ID (via the jti claim), and server-side these IDs can be matched against this blacklist. When you log out, you send a request to the service that your current token be blacklisted. Because JSON Web Tokens are short-lived, the blacklist need only contain tokens valid for validity period…
Yeah, and that's kinda sad because now you have to check a signature AND query a database!
Well you cache the blacklist and push updates, so it has no real performance cost. Just a tad more dev time
Re: JSON Web Tokens should be avoided
#38Earlier quoted context omitted.
Session invalidation is possible though, by maintaining a (short) blacklist of tokens on the server. JSON Web Tokens can be given an ID (via the jti claim), and server-side these IDs can be matched against this blacklist. When you log out, you send a request to the service that your current token be blacklisted. Because JSON Web Tokens are short-lived, the blacklist need only contain tokens valid for validity period…
Yeah, and that's kinda sad because now you have to check a signature AND query a database!
s/database/in-memory-map/g should be fine - and suddenly it's pretty lightweight (subtracting service restarts and a highly available message bus of course :)
Re: JSON Web Tokens should be avoided
#39Token invalidation being an issue depends on the app.
Checking against a blacklist / some secondary measure may only be required for important actions such as changing password, checking out, etc.
Re: JSON Web Tokens should be avoided
#40A lot of people are talking about the "none" algorithm issue, but the more recent vulnerability[0] is more telling: The report to the working group mailing list[1] led to the point that the standard had a "security considerations" section in the RFC, and this particular issue was never covered.
And now there are difficulties around the fact they cannot update an RFC which people will refer to for years.
It's not a vulnerability in one or two libraries - it looks like just about every made the same mistake, which points to something much more broken.
[0] https://auth0.com/blog/critical-vulnerability-in-json-web-en... [1] https://www.ietf.org/mail-archive/web/jose/current/msg05613....