JSON Web Tokens should be avoided
paragonie.com
JSON Web Tokens should be avoided
1–10 of 304 posts
Re: JSON Web Tokens should be avoided
#2Well how about that; I had no idea there was a specific standard for this type of thing nor did I realize the client could specifically request a type of algorithm to be used. That seems incredibly short sighted; why wouldn't you let the server handle that and make the algorithm completely transparent?
> Just use cookies over HTTPS.
Maybe it's because of my experience working in environments where cookies were disabled but I just try to avoid them where possible nowadays for my authentication handling. Instead of storing the equivalent of a session / token id in a cookie I just store it in sessionStorage and include that in requests.
Re: JSON Web Tokens should be avoided
#3It would really help encourage the uptake of better alternatives like libsodium if it were standardized. Just referencing some random library can scare decision makers; whereas referencing an IETF official document or ISO standard makes them just take it as given.
The same problem exists with serialization formats - you have XML and JSON, both of which are standardized and have an "official face", although JSON was not born that way. Google protocol buffers are quite superior in many ways, yet as they are just some product of some company and not an actual standard, decision makers are scared of them.
Technology experts do not get to make all the technical decisions, so standardization matters, even if for the stakeholder feelgood factor!
Re: JSON Web Tokens should be avoided
#4It depends on the security model, but in the long term I think sessions are the way to go. It becomes much easier to differentiate the different clients that connects to the API
Re: JSON Web Tokens should be avoided
#5This post says "it's insecure if you do it wrong".
Well.....
Re: JSON Web Tokens should be avoided
#6"Send a header that specifies the "none" algorithm be used"
Why would an issuer ever let a client decide what algo to use?
"Send a header that specifies the "HS256" algorithm when the application normally signs messages with an RSA public key."
Again, under what circumstances would a header be used by the client to ask for a specific implementation?
What about encrypted client side cookies - would you let the client "send a header" to specify which key to use???
The only problems you highlighted are serious input validation issues and a naive, broken trust model.
Re: JSON Web Tokens should be avoided
#7The "none" algorithm set in header is a well known problem and, for example, nodejs most used library automatically uses asymmetric keys when one is given, ignoring the header (https://github.com/auth0/node-jsonwebtoken/blob/master/verif...)
As long as the problem is known to the developers and the key is specified, I think the biggest issue of JWT is the lack of session invalidation (that is, if you log out your already emitted tokens are still valid until their expiration), but it's a good tradeoff for not having server sessions.
Re: JSON Web Tokens should be avoided
#8JWT is bad, signed tokens are fine. Session cookies suck and don't scale. Just copy code of MessageVerifier from Rails, it's simple.
Re: JSON Web Tokens should be avoided
#9It would really help encourage the uptake of better alternatives like libsodium if it were standardized. Just referencing some random library can scare decision makers; whereas referencing an IETF official document or ISO standard makes them just take it as given. The same problem exists with serialization formats - you have XML and JSON, both of which are standardized and have an "official face", although JSON was n…
... yes, but... sidenote, JSON is almost unreasonably easy to grok, and translates well into every web-abstracted language, making it the clear-and-away winner.
At the end of the day, tech doesn't win. Developer experience wins. By the time companies have the resources to fight for every iota of performance, they've already won because they shipped product faster than everyone else --- why? Their developers could move and iterate quickly.
Re: JSON Web Tokens should be avoided
#10"Send a header that specifies the "none" algorithm be used" Why would an issuer ever let a client decide what algo to use? "Send a header that specifies the "HS256" algorithm when the application normally signs messages with an RSA public key." Again, under what circumstances would a header be used by the client to ask for a specific implementation? What about encrypted client side cookies - would you let the client…
[deleted]