JWT is bad, signed tokens are fine. Session cookies suck and don't scale. Just copy code of MessageVerifier from Rails, it's simple.
A JWT is a signed token - or at least, in most cases, is?
JSON Web Tokens should be avoided
71–80 of 304 posts
Re: JSON Web Tokens should be avoided
#72I don't see any valid arguments in the post. The issues raised are either mis-implementation or misuse of JWT. All I am getting is "JWT can be misused in such such way that makes your application vulnerable. And neither its standards nor libraries prevent that, so it sucks". But when is the last time we see any technology successfully prevented people from being silly?
+1. I read the article and ended up with a TLDR where I expected some explanation and facts.
It's a good thing that cookies have never been used in a bad manner. /sarcasm
Re: JSON Web Tokens should be avoided
#73I don't see any valid arguments in the post. The issues raised are either mis-implementation or misuse of JWT. All I am getting is "JWT can be misused in such such way that makes your application vulnerable. And neither its standards nor libraries prevent that, so it sucks". But when is the last time we see any technology successfully prevented people from being silly?
> But when is the last time we see any technology successfully prevented people from being silly?
You can never stop someone sufficiently motivated to shoot himself in the foot from doing it. But you can make it harder for those who would do it be accident by providing more safety features - in case of security this is usually seen as a good idea (safe defaults etc.)
Re: JSON Web Tokens should be avoided
#74"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…
> Why would an issuer ever let a client decide what algo to use?
Right, so, why is this in the spec?
Re: JSON Web Tokens should be avoided
#75I use JWT in a couple of projects and it never once occurred to me to let the client decide the algorithm. I am not sure what use-case would necessitate something like that.
Guess that shouldn't be in the spec then.
Re: JSON Web Tokens should be avoided
#76This post says "it's insecure if you do it wrong". Well.....
I hear where you're coming from... but this is also the bane of developer existence. We all have to accept that, every year, tens of thousands of new developers looking for jobs enter the market. There's such a demand for developers that these people get jobs. So footguns, as much as we like to play high-and-mighty and say, "well, duh, don't shoot yourself in the foot" are a real, existential risk to a lot of compani…
I was under the impression that newly minted developers would use existing libraries and frameworks, which have already take security into account.
Re: JSON Web Tokens should be avoided
#77The criticisms of JWT seem to fall into two categories: (1) Criticizing vulnerabilities in particular JWT libraries, as in this article. (2) Generally criticizing the practice of using any "stateless" client tokens. Because there's no great way to revoke them early while remaining stateless, etc. The problem is that both of these groups only criticize, neither of them can ever seem to actually recommend any alternati…
I don't care if you want to use stateless client tokens. They're fine. You should understand the operational limitations (they may keep you up late on a Friday scrambling to deploy a token blacklist), but, we're all adults here, and you can make your own decisions about that.
The issue with JWT in particular is that it doesn't bring anything to the table, but comes with a whole lot of terrifying complexity. Worse, you as a developer won't see that complexity: JWT looks like a simple token with a magic cryptographically-protected bag-of-attributes interface. The problems are all behind the scenes.
For most applications, the technical problems JWT solves are not especially complicated. Parseable bearer tokens are something Rails has been able to generate for close to a decade using ActiveSupport::MessageEncryptor. AS::ME is substantially safer than JWT, but people are swapping it out of applications in favor of JWT.
Someone needs to write the blog post about how to provide bag-of-attributes secure bearer tokens in all the major programming environments. Someone else needs to get to work standardizing one of those formats as an alternative to JWT so that there's a simple answer to "if not JWT then what?" that rebuts the (I think sort of silly) presumption that whatever an app uses needs to be RFC standardized.
But there's a reason crypto people hate the JWT/JOSE/JWE standards. You should avoid them. They're in the news again because someone noticed that one of the public key constructions (ECDHE-ES) is terribly insecure. I think it's literally the case that no cryptographer bothered to point this out before because they all assumed people knew JWT was a tire fire.
Re: JSON Web Tokens should be avoided
#78The author of http://blog.intothesymmetry.com/2017/03/critical-vulnerabili... here FWIW. Personally I would not be so drastic. JOSE per se is not too bad (at least the idea is cool). Some crypto choices though have been really arguable...
Re: JSON Web Tokens should be avoided
#79Complaining about OAEP when RSA-OAEP is perfectly safe seems needlessly straw-grasping, the other complaints (should) stand perfectly well on their own. I've used JWT in three languages and the API has always sucked, really badly. I always end up with a verbose heap of gunk - and in some cases, like jwt-go, there is not even a complete example of use in the README + docs. mfw. It should not take multiple steps to sig…
I agree. The OAEP thing was weird.
Re: JSON Web Tokens should be avoided
#80The criticisms of JWT seem to fall into two categories: (1) Criticizing vulnerabilities in particular JWT libraries, as in this article. (2) Generally criticizing the practice of using any "stateless" client tokens. Because there's no great way to revoke them early while remaining stateless, etc. The problem is that both of these groups only criticize, neither of them can ever seem to actually recommend any alternati…
Either way, if you're serving up a REST API to a JavaScript UI... what's NOT a good option is server-side session state (e.g. Java servlet sessions)
Can you explain what you mean, as oppose to other kinds of session tokens?
Roy Fielding makes it abundantly clear[0] in the seminal delineation of REST that
We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.
[0]https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...