Hacker News Reader

Comment by AndrewSChapman | Hacker News Reader

I've read several articles along these lines now I tend to think the arguments are pretty weak.

In this media rich age, the data size argument is a bit silly.

The "you're going to hit the database anyway" argument whilst probably accurate in most cases, doesn't invalidate that JWT allows for one or more fewer database hits on every request.

Having built-in integrity checking is definitely a feature. Just because you can do it without JWT doesn't mean that it's not useful that JWT does it.

IMHO the biggest argument against the use of JWT is that you can't easily invalidate JWT sessions. Should you need to dump a users session or if the information contained in that session token has become invalid then you might be in trouble. For my use cases so far however this hasn't been a problem.

JWT is a fine solution for quite a lot of use cases. As with everything tech, just be aware of the limitations and choose wisely.

View on HN

I've been fond of [1] and [2] for a more focused argument against JWT for sessions.

The JOSE standards (of which JWT is a member) are error-prone and have had numerous critical security-affecting bugs due to how they were designed. [3]

To remedy that, I proposed PASETO. [4]

I still don't recommend PASETO for sessions, because of the arguments laid out in [1] and [2].

[1] http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo...

[2] http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-...

[3] https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...

[4] https://paseto.io

+1 There are so many arguments against JWTs as session tokens. It's just so long and so much work to describe all of it and respond to each argument against each one. Sven does the best possible job of summarizing it up.

Also: PASETO is really fantastic, thanks for creating it! I've started mentioning it in my talks and using it for internal projects -- I really enjoy it so far =)

"alg": "none" comes to mind. Azure had it unpatched for close to a year. God knows how many corporate mailboxes and contact directories flew through that hole that went largely underreported. All what attacker had to know was the id number of the app that got previously preapproved, a trivial thing, given that it was given out in oauth requests for user permissions.

The industry will continue pay a dear price for mixing the rogue and unruly realm of web development, with what previously was a domain very conservative "enterprisey java development shops" where everybody dresses in a suit, and at least have some formal CS background above bootcamp course.

I concur with the author about session usage of JWT since it has little value (and if you did, just use it for it's signing feature and still have it just contain a random session identifier). The reasons for defending it in that use seem to be about what's not bad, but rarely about what's good.

But JWTs have value for API tokens as they can embed an expiration date for the caller in a known format. But the idea of stateless JWTs with a bunch of valid data for use on successive calls by the server is a bit much. You should contact your auth store of record per invocation for various reasons.

Like you said, be aware of the issues with chosen sig algorithms and be exact on what you choose and just leverage JWT as the format, not blindly following the generation libraries without investigation.

"about session usage of JWT since it has little value "

Two weeks ago, I stood in front of a room full of senior developers and architects and asked them "How will we avoid making a leading 'Does the user have permissions?' call or wrapping the request in a try catch in case the user doesn't have access without JWT claims.

They all got mad. Then they conceded that they don't have a solution. Do you have a solution? If not, you can't replace JWTs.

But... that's not really something you _have_ to avoid. Check permissions, if they fail the test -> http401 (for an API) or some user-friendly redirect. Something similar to this is how things work without JWT currently, so it's only a problem if you make it one.

You seriously think making a redundant call or wrapping every. single. controller into a try-catch is better than having claims pulled out in a request pipeline (before even touching the controller) and doing `if(hasAccess){do thing} else {unauthorized}`?

It sounds like you're arguing from a very specific mental model of an ACL workflow.

In my CMS, I had support for granular permissions. So you could do this:

  if ($user->can('update')) {
    if ($postData) {
       $this->processUpdate($postData);
    }
    // display edit form
  } elseif ($user->can('read')) {
    // read-only
  } else {
    return error_403_condition();
  }

JWT wouldn't have helped much.

I will look into this more and come back with what I figure out later on. Thanks.

That looks similar to a try/catch... You just called it if/else.

Also, why can't you make the database request in the request pipeline, right before that "if(hasAccess)" statement. You don't need JWT for this...

You are already wrapping all of your controllers...

If your controllers are asp.net mvc controllers you can decorate them with permission attributes (see the relevant docs for your version).

Pretty sure most frameworks have a way to structure your code for permission checking.

If you're not willing to risk users making requests with stale permissions (which is a risk you shouldn't accept lightly), then JWT requires that you hit something at the start of processing every request anyway. It can either be a token blacklist service (really just a key-value lookup), or it can be an auth/permission service.

The auth service/query is higher per-request overhead, but it also keeps things simple. And simple is what you want unless you're dealing with ridiculous scale.

I don't know what you're working with, but you don't need a JWT to figure out access in the request pipeline. A session ID does the same thing and allows you to associate a session to a user, and most frameworks are capable of doing this already (e.g. django has middleware that can do this)

Even if we accept the assumption that you actually have to avoid it (I don't!),here are some:

- Database permissions, including row-level security

- Macaroons

- PASETO

- Fernet/secretbox/HMACing a JSON blob

These are different approaches so it's hard to summarize, but they all either give you a property JWT doesn't or avoid a flaw JWT has. You can't seriously believe that nobody did this before 2015.

This is a real production issue for me, so could you please elaborate on why you think one of these (whichever you prefer) is better or link me to a source?

I'm not sure how you intended this comment, but it reads a bit like a solicitation for lvh to do free work.

I wrote PASETO, with a lot of feedback from cryptographers and security engineers, to avoid a lot of the design flaws of JWT.

Learn more about it here: https://paragonie.com/blog/2018/03/paseto-platform-agnostic-...

You can find a lot of implementations available: https://paseto.io

(Also: You almost certainly want to use v2)

I wanted a link to your solution because I have never heard of it before. Not sure where you are getting the "free work" part of this from, unless you want to be paid per comment. Careful with the free advertising with PASETO there.

Joking on the last two sentences, but that's how you sound when you accuse me of wanting free work. Thanks for the links.

> Not sure where you are getting the "free work" part of this from, unless you want to be paid per comment.

Oh, that's easy to explain. You said:

> This is a real production issue for me, so could you please elaborate on why you think one of these (whichever you prefer) is better or link me to a source?

Specifically:

> This is a real production issue for me,

If you want a cryptographer (i.e. lvh) to solve a real production issue for you, that would in most cases be a business transaction.

>If you want a cryptographer (i.e. lvh) to solve a real production issue for you, that would in most cases be a business transaction.

If we're being uncharitable, yes.

But the parent didn't ask the other to sit down and write code, or consult, or design a system for them. In the course of an already existing discussion on the merits (and the faults) of various session auth schemes, the parent asked the other person to elaborate on why he said something.

Which people do all the time without getting paid, and the grandparent was already doing (offering his opinion) anyway.

So that it's a "real production issue" for them is irrelevant. I participate in conversations all the time concerning something that is a real business issue for me or the others, and nobody feels like we should be getting paid because we have a talk. In fact half of the discussions on HN concern frameworks, tools, deployment schemes, etc, we use in production, and we have "real production issues" with and are interested in getting other's opinions in the discussion.

I think one can easily see how this is different from a proper consulting gig.

>"If you want a cryptographer (i.e. lvh) to solve a real production issue for you, that would in most cases be a business transaction."

That sounds like what some kind of caricature of a high street lawyer who charges from the first minute, even people they casually talk with. As if answering a comment on HN would equal to doing a consulting gig.

It's doubly uncharitable since the parent asked nicely and also added "or link me to a source". Should he be charged for a link too?

> So that it's a "real production issue" for them is irrelevant.

I respectfully disagree.

If it was truly irrelevant, it didn't need to be brought up in the first place.

But it was, and it's what made me believe that the other person was trying to solicit for a security expert to solve a production problem for them without an invoice being involved. It was relevant to my interpretation.

They insist they didn't mean it that way, and I believe them, but it was still relevant.

Whether or not it was relevant in the comment I replied to, it became relevant once it was entered into the discussion.

You can call that "uncharitable" if you want. I don't really have a horse in that race.

>If it was truly irrelevant, it didn't need to be brought up in the first place.

It's not like people must have some hidden agenda, or that they necessarily consciously "bring things up" with some ulterior motive.

The parent just shared some context, that he has an issue related to the discussion. If anything, if they really had some hidden motive, like getting market-worthy consulting as part of a HN comment reply (!), they'd have, well, hidden the fact that they have this problem at work.

It's totally common to casually mention that "you know, this issue we're discussing on this thread I also have a work, and why do you say this approach sucks and which do you then suggest".

In fact it happens all the time on HN, between regular developers, the occasional star scientist or programmer (from Alan Kay to Ryan Dahl and Dan Brown), and even far more important and busy pros than some security expert, and I've never heard anybody counting their lost pennies from what they'd have gained if they charged for talking to them...

It's also not like the person the question was addressed to can't handle the matter themselves, and e.g. not answer if they fill they need to be paid for their musings...

> It's totally common and perfectly innocent to casually mention that "you know, this issue we're discussing on this thread I also have a work, and why do you say this approach sucks and which do you then suggest".

The structure of the comment in question is also relevant:

"This is a real production issue for me, so could you [...]"

This reads like a demand if you parse it in spoken English.

If it helps, imagine working in retail and hearing a disgruntled customer ask you to hurry up and give them priority service. Their request might be structured like, "I need to pick my kids up from school at 3, so could you hurry it up?"

Your word choice is far less demanding than theirs. If they wrote their comment the way you just wrote yours, it wouldn't have struck me that way.

The entire reason I brought it up was because I was unsure of the intent. They clarified their intent. I believed them. Life moved on. You're still trying to litigate this.

But none of this matters. What matters is, they didn't intend it that way, and JWT sucks.

> In fact it happens all the time on HN, between regular developers, the occasional star scientist or programmer (from Alan Kay to Ryan Dahl and Dan Brown), and even far more important and busy pros than some security expert, and I've never heard anybody counting their lost pennies from what they'd have gained if they charged for talking to them...

To be fair: me neither. But knowing how humanity is, I wouldn't totally discount that it does happen somewhere on the Internet (maybe even HN).

@CiPHPerCoder Looks like there is a limit to reply nesting, so replying here. Come on, I asked for a link or a description. I didn't even provide a single word about our stack. Nor do I know who the guy is, or anyone on this site, for that matter.

I'm happy to hear you didn't mean it that way.

We wrote a big-ol blog post about inter-service auth that has a lot of relevant stuff: https://latacora.micro.blog/2018/06/12/a-childs-garden.html

RLS means your database understands what a user is allowed to see and not allowed to see. It is usually much simpler to express authz in a SQL constraint than it is in code. It's also harder to forget, so you don't get an authz failure in like, one endpoint.

I will check it out, thanks.

I wouldn't recommend Macaroons so lightly. I spent 2 months researching them for internal use, reimplemening them from the paper and comparing with existing implementations.

There are numerous practical issues with Macaroons: the caveat format is not standardized (both binary and allowed claim types), that matters a lot when using third party caveats. There are some de facto formats but they are full of issues (e.g. date format not exactly ISO).

Validation of a set of Macaroons requires walking a graph, that needs cycle detection, implementations that I've checked do not allow nested third party caveats, that invalidates one reason to use them.

Attenuation is nice but it doesn't play nice with third party caveats (hash is used as a key for decryption, appending to a third party caveat changes hash).

Then there are implementation errors such as: https://github.com/nitram509/macaroons.js/blob/master/lib/Cr...

Some of these issues could be removed by slightly changing implementations but the de facto implementation basically froze it. (then there is a fact that the de facto impl already changed some aspects from the paper, e.g. calculation of hash for appended third party caveat).

> We wrote a big-ol blog post about inter-service auth

Wow what a treasure trove of goodness. Thank you!

> How will we avoid making a leading 'Does the user have permissions?

You don't avoid it, you do it. Gathering simple user info including permissions should be the first step at the request boundary and it can traverse the life of the request. If you foolishly use a stateless token to read permissions, you're gonna be annoyed when changes you make don't take effect immediately. I trust your seniors know this (of course different situations and caveats apply, but this is referring to the general approach).

I am well aware of this. What you are advocating is an unnecessary database call on every single request.

That's exactly what I'm advocating, it's not unnecessary, and should be trivial. If you are afraid of overhead, you can have a caching layer ala Redis or Memcache or even local process memory (but don't eagerly optimize, the costs are trivial to make this call). Either way, you need to communicate with an updated cache or a user record of store. Don't trust information sent to you from the client because it may not be accurate with updates (there are exceptions to this when you can tolerate staleness, but for the general approach this is what you want to do).

What's wrong with a db call on each request? A single server can handle over 10,000 of those per second..

Generally a big DB query is made when the user enters the site or makes the first API request to load all relevant user data. Then the data is stored in a cache system, which will be faster and cheaper than having the user send the data on every request.

Most modern web frameworks will do this out of the box with a little configuration.

Specifically, I've had good results with Redis, applicable for the majority of web apps. In some rare cases where even local network is too slow, use of local memory storage has worked well (at the cost of greater memory usage and more complex invalidation procedures).

But before optimizing user permissions, in my experience there is much more to be gained from optimizing other types of DB queries.

For signout we use token and user revocation lists represented as bloomfilters that services can poll or query directly if they need more consistency. This actually does work well in practice at very large scales efficiently we found.

> The "you're going to hit the database anyway" argument whilst probably accurate in most cases, doesn't invalidate that JWT allows for one or more fewer database hits on every request.

Using random session cookies does not prevent you from using caches.

> In this media rich age, the data size argument is a bit silly.

JWTs aren't cached, and cookies are sent on every request, so there's a much bigger multiplier on JWT size cost than there is on media size cost.

For invalidating, you just need to store the JTI (id, as a UUID) of the token in the DB. On challenge, you just compare the JTI of provided token to the one stored, and if there's a mismatch you 401. For doing the actual revokation, you can just clear the active JTI and have app code that would reject that. It's certainly arguable if this is worse or better than session tokens, but it's not unsolvable.

It's not unsolvable, just incompatible with the premise of "use JWT for sessions" which is to avoid the database hit entirely.

Yup, I can't believe the author didn't go over something like this. It's the perfect use for the JTI. Put it as a column on your users table and all set. We use a Ruby authentication library that does exactly this.

I have trouble understanding why session invalidation with JWT's is challenging. The JWT itself contains an IAT (issued at time) describing when the token was created. To invalidate all sessions, you can store (in your DB, or other persistence service) a 'invalidated at' date. Any request with a JWT that was issued before this 'invalidated at' date can be considered to be invalid.

> I have trouble understanding why session invalidation with JWT's is challenging.

Imagine you're connecting to a service that uses JWT for sessions so they don't have to store anything server-side.

Let's say you have a token with an IAT of yesterday and and EXP of, say, a month from now.

Further, your browser gets infected with malware and the attacker steals your token. You rebuild your computer from a fresh install.

How does the service invalidate the token while still being stateless? It has 30 days left.

Your next move is:

> _

You should have tokens with short durations that are refreshed upon use. That greatly reduces the odds of a token being stolen or leaked and then used before it expires.

You're getting closer to the problem:

JWTs were designed to be single-use (or very, very short lived) claims (with optional cryptography features).

It was never meant to be "offload everything to the client and obviate the need for server-side storage". It was never meant to be the new hotness among the NoSQL Scalability crowd.

Sure, but then you’re calling your DB to validate the JWT every time anyway. You’ve just removed the whole “JWTs are cool because they’re stateless” benefit.

But that's just it- only for all tokens.

What if a user changes their password? Until that token hits its timing limit, they've got free reign. Or, you use denylists, requiring the database again.

I’ve gotten used to using the Amazon style of using an accessToken and refreshToken. The accessToken expires in 5 minutes and the refresh is used to get a new access token. So at most you have a 5 minute window of acesss.

More boilerplate Code and bandwidth but it works fine.

My issue with the article is that we’ve generally stopped building our own auth and now lean into using cognito or auth0 for authentication for the sites we build for third parties. Those services provide so much more out of the box then a home rolled solutions (MFA etc).

The problem with blacklisting is that then you end up doing the database hits and avoiding those was one of the reasons for adopting signed tokens.

I see the value of signed tokens in complex infrastructure where you want to have one heavily guarded system doing the authentication and token assignment and then a bunch of other systems just validating the tokens.

>> IMHO the biggest argument against the use of JWT is that you can't easily invalidate JWT sessions

That's true. JWT is great for WebSocket connections because you can make the expiry really short (you could even make it 1 minute) and you could re-issue a new token in real-time every 50 seconds just before the previous one expires. Then if the user goes completely offline for 1 minute, then they lose their session (the JWT becomes invalid).

I think the most important part of that is "you're going to hit THE database". A single session token is more efficient but tightly couples all services. There's a single point of failure at whichever server does auth. Unlike JWTs, degradation or outages in token servers ripple through the whole system.

So when would you use session tokens? When you have a small application that you confidently predict will never outgrow being a monolith.

"In this media rich age, the data size argument is a bit silly." I couldn't agree more !! Its just so much easier to do JWT specially if you got more than one server(api)

Reply on news.ycombinator.com