Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Web Tokens should be avoided

paragonie.com

Post reply on HN
Print view View original

61–70 of 304 posts

Re: JSON Web Tokens should be avoided

#61

Post by tveita »

fcvarela wrote: post #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…

> Why would an issuer ever let a client decide what algo to use?

JWT, like SAML, is made to support separate identity providers and the service providers. In the spirit of generality, this means the identity provider(s) could be from a different vendor, operated by a different organization. E.g., you could let users access their account on your service based a token issued from Google. But that means Google chooses the algorithm, not you!

And it's a standard, so you don't have to write any code of your own. Just import the right middleware for your framework and you're set!

So the temptation is there for library authors to support all the defined algorithms, and just enable everything by default to be as compatible as possible - after all, you can just look at the header to see which algorithm to use!

Re: JSON Web Tokens should be avoided

#62

Post by andy_ppp »

BinaryIdiot wrote: post #2

Well 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 disabl…

Yes, this prevents CSRF without tokens too.

Re: JSON Web Tokens should be avoided

#63

Post by hardwaresofton »

Can anyone think of some criticism for simply storing an API key and secret in localstorage for a web client? It's 50% bridging the gap between using cookies and a normal API and 50% simplifying frontends. The scheme I'm currently using on a project goes like this:

1. Web client ("offline-first" SPA app) hits HTTPS backend in with username and password

2. Web client receives a a generated API key and secret, which expires in a week/month/whatever.

3. That API key and secret gets stored in localstorage on the client-side by the web app for future use (as long as they're logged in)

4. Web client includes the API key and header in requests to the HTTPS backend of the app.

Of course, there are more specifics that could be added like device fingerprinting, invaliding old web-created tokens when a new one is created, and classifying api keys/secrets to certain devices, but I think those things are ancillary.

This is obviously very very close to what a cookie would be, and the only way I could see it going catastrophically wrong is the browser being compromised (whether the vector is XSS, or some other leaky surface on the user's computer). Regular cookies and JWT have the same issues.

I can't think of a failure mode that's any worse than HTTPS cookies or JWT, and it is dead simple. I've really been trying to find some flaws in that plan lately but I can't.

Re: JSON Web Tokens should be avoided

#64

Post by [deleted] »

arethuza wrote: post #25
kierenj wrote: post #22

One advantage I think not mentioned by some of the linked articles is that the JWT's claims are readable on the client. It's a pretty good plus, for me: no additional round-trips to the server to grab key user details, which can be put into claims, or check access levels (via roles, permissions, or other types of claim). This doesn't discount the disadvantages, of course.. I think as with everything it's a case of th…

Out of interest, do you check the authenticity and integrity of the JWT on the client side?

[deleted]

Re: JSON Web Tokens should be avoided

#65

Post by zimbatm »

yarper wrote: post #52
Klathmon wrote: post #49

Earlier quoted context omitted.

If I can offer some advice in the other direction, don't use cookies. I tried to do the right thing, use HTTP-only cookies set over an HTTPS endpoint only to find that it's stupidly complicated and has a lot of annoying edge cases. Turns out iOS's webviews don't like them, iOS in general doesn't like them to be on api.hostname.com if the app is on app.hostname.com, you can't validate if you are logged in or not witho…

Ideally you need to use httpOnly cookies to store your JWTs too.

If the SPA is doing XHR requests then a localStorage is also an option. It has the advantage that the application can control on which requests the token is being sent, in contracts with cookies where they are sent for any requests on then domain.

Re: JSON Web Tokens should be avoided

#66

Post by zimbatm »

cptskippy wrote: post #56
Klathmon wrote: post #49

Earlier quoted context omitted.

If I can offer some advice in the other direction, don't use cookies. I tried to do the right thing, use HTTP-only cookies set over an HTTPS endpoint only to find that it's stupidly complicated and has a lot of annoying edge cases. Turns out iOS's webviews don't like them, iOS in general doesn't like them to be on api.hostname.com if the app is on app.hostname.com, you can't validate if you are logged in or not witho…

Wouldn't you need to assign your cookies to the TLD for them to be accessible to both subdomains?

It would also send them to the CDN if it's hosted on a cdn. subdomain.

Re: JSON Web Tokens should be avoided

#67

Post by zimbatm »

sbergot wrote: post #45
endymi0n wrote: post #38

Earlier quoted context omitted.

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 :)

s/in-memory-map/cache-server/g if you happen to have a load balancer without sticky session.

In both cases there is a DB somewhere storing the list. The difference is that with the blacklist the server can keep an in-memory cache because it's so small. Sessions don't need to be invalidated atomically so the blacklist can be refreshed every couple of seconds.

Re: JSON Web Tokens should be avoided

#68

Post by RegEx »

akfish wrote: post #43

I 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?

https://github.com/rails/rails/issues/5228

Re: JSON Web Tokens should be avoided

#69

Post by kierenj »

jacopofar2 wrote: post #7

The "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 a…

In terms of invalidation, I think a case-by-case basis is best, as it often is.

For example -

If some critical part of your app depends on a user's account or session being still valid, just do the check on that endpoint call (grab the sub/ID claim from the JWT and hit the DB, or similar).

The rest of the time - viewing stats/feed/whatever, admit that if the user had a valid token issued to them 5 minutes ago, it's probably OK to send them stats without having to check revocation (or whichever benefit of JWT you're exploiting).

Thing is, this at least gives you the /option/..

Re: JSON Web Tokens should be avoided

#70

Post by StevePerkins »

The 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 alternatives.

I could care less about JWT per se. I'm happy to implement a similar pattern with something else (e.g. store a secure cookie post-auth, skip all the refresh business and just let it expire when it expires, and employ an ugly revocation strategy only if absolutely necessary). I don't need JWT for this.

If I'm providing a REST API, then I'd prefer a token string that I could pass as a header value rather than forcing the use of cookies. Although I suppose you could argue that a cookie is just another header value.

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). That requires you to either: configure your load balancer for sticky-sessions, or employ a solution to share session state across all your server-side instances (which never works very reliably). Moreover, relying on a session isn't a very RESTful auth strategy in the first place.

So if I'm writing a SPA in 2017, then I'm definitely taking a client-side approach and running afoul of the #2 critics. And since JWT is so widely implemented (e.g. if I use a "Login with Google" option then I'm using JWT), I'm probably running afoul of the #1 critics too.

These criticism are fine, I guess. There's no faster route to blog clicks, book sales, speaker invites, and consulting dollars than: (1) telling everyone to jump on this year's hype train, or (2) telling everyone that last year's hype train sucks. What the world really needs is a bit more actual prescriptive recommendations of what to do instead.

Post reply on HN