Stop Using JSON Web Tokens (JWTs) for Authorization!

Hey, and welcome to this lightning talk on don't use JWT for authorization. My name is Sohan Maheshwar. I work in a startup called AuthZed. And the story behind this talk is it's actually pretty funny.

Some time ago, I released a YouTube video called Don't Use JWTs for Authorization. Yes, I know I have the very YouTube face in the thumbnail, etc. But what happened was about a week after putting this video out, this happened. About 35,000 views in just a week and turns out sometimes people on the internet can be not so nice because I got a lot of comments like this about calling me a genius but I think sarcastically.

People saying, hey, I have no idea what I'm talking about, something about a JWT marketplace, which I'm not sure what that is. Questioning if I've read the RSC for JWT, which admittedly is quite a boring read. And this one I think speaks for itself. So I thought I'll give this talk at a conference and see if people actually tell me this maybe in person or in the comments. But here goes. So the idea is don't use JWTs for authorization. To set context, JWTs or JSON Web Tokens are essentially a data exchange format. In this format, there are three things.

There's a header, a payload, and a signature. The two things we don't care about too much for this talk is the header, some stuff about an algorithm type, etc. and the signature, which is usually a cryptographic signature. Let's not focus on that. The part I want you to focus on for today is the payload. And this payload, again, has some data. And usually there's a name, a time of expiry, which is when the token expires, a role, and also scopes. And this is where things get interesting because how people have used JWT for authorization is in the scope add things like admin or read or write, etc. and associate that with permissions for a person in an app. So say I have read permissions and you have write permissions, that would be included in the scope and this token would be passed around when a service is created.

Now, interestingly, this scope isn't even from the original JWT or the JWT spec and actually comes from a different spec, which is the OR2 token exchange spec. So, you know, in a way, it maybe wasn't even created for this specifically for authorization and permissions, but here we are using it fairly regularly. The underlying assumption behind using this is permissions don't change during a token's lifetime. And that is very, very false, right? That's absolutely not true, especially in the complex systems that we are building today.

So I'm going to give you three reasons why you should not be using JWTs for your authorization. And again, when I say authorization, I mean fine-grained permissions.

Problem number one and this is the biggest problem with using JWTs in authorization is there is no meaningful way to revoke a token once it's out in the wild. So say you add like a bunch of scopes in a token and you send it out in the wild and something changes like a user is removed from an organization. Maybe their role is downgraded from admin to viewer or maybe they've just been removed from a certain file. There is no meaningful way to take that back or to revoke this token once it's out. You essentially have to just wait until the expiry.

And of course, you can think of things like refresh tokens, etc. But again, that is not a great user experience for those whose roles or users or whatever have stayed the same. You're sending out a refresh token for a bunch of people. So the idea is a JWT is self-contained. It's stateless and you're not checking the state of reality with the centralized authority. Once that token is sent out, reality changes, but the information in that token doesn't change.

And this actually has a name and it's called the new enemy problem. So I'll describe it to you. You have Kara here who has access to secret plans and so does Lex, but Lex is a villain. So Kara removes Lex's reader permissions from this file. Here's the important part. Kara adds new secrets. So at this point, Lex should not be able to access this new secret. But because of this, you know, the fact that Lex has permissions in this token, Lex attempts to read this document and can see it. And you know, chaos ensues. So this is the new enemy problem, which is described in a white paper written by Google called Google Zanzibar. Now, this paper was released in 2019 and it documents how Google's internal authorization system works across Maps, YouTube, Sheets, etc. So there's a good chance you have used it at some point of time. We'll come back to this in a bit.

Problem number two is scopes don't really scale. So even if your use case has something where you're like, it's fine. Things don't change too often. I don't need to revoke it. You can't scale your scopes to fine-grained permission. Scopes are too broad. So for example, profile admin is what data are we talking about? Is this the current user's profile? Is it the whole website? It is very hard to say this. This has actually plagued GitHub's REST API for many years, if you ever used it. In our day and age, we really look for fine-grained authorization. So a user like you might have access to millions of software objects where in reality, in a production system, you probably want to scope down your access to just the things you're working on or are related to.

For instance, issue//authset//spice-tv//something//author. You can give access to only that as opposed to just issuing author to anything. And with scopes and with JWTs, you can't do this. You can just say add more scopes, add more tokens, but you're just passing along this massive token up and down, and most servers and the JWT spec doesn't even support it. You can just Google this and you'll see people facing this problem. So not a great idea. And number three, final problem is, again, in a complex environment like an enterprise system, you cannot predict permissions.

Essentially a JWT is created at a request entry point and it just goes downstream. But for that, it needs to know each downstream service and what permissions are needed, you know, there and thereabouts. And with a microservice architecture, which is how a lot of us do architecture and code nowadays as opposed to monoliths, this actually is impossible. And people have solved this by saying, you know what, I'm going to slightly over provision a token so that each downstream service has access or gets to do what it wants. But this is very bad. Please don't do this, because you're basically giving extra permissions that leak downstream. Your attack surface is increasing and you risk, you know, privilege escalation. Maybe one service or something is overprivileged and someone with malicious intent can get in there and do bad stuff.

And frankly, this problem is going to compound with things like AI agents where you really want to scope down what your AI agent can do. And again, JWTs and passing around a token with scopes is not the way to do it. A few years ago, there was actually a fix for this very problem in the shape of something called a macaroon, which I think is a pun on the word cookie. And again, there's a white paper on Google about macaroons. It's actually a pretty cool piece of tech where, you know, it's more flexible and it uses a reduced scope or an attenuation model where each service is given the things it needs to, you know, perform a task. So you're attenuating like that service.

The problem was, it was very complex to implement. It's hard to adopt. Again, look on YouTube, there are enough talks about how macaroons are cool, but in reality very hard to actually implement. All this to say is access control is very complex. Our systems nowadays are not the same as they were 10, 15 years ago. They are vast. They talk to other systems and they are complex and access control becomes hard. And it's not just me saying it. If you have ever heard of OWASP or Open Worldwide App Security Project, it's an industry company, they make a list of top 10 security risks for web apps.

And this list is out every four years. The last two lists have been topped by broken access control. So this is the biggest risk to a web app. Crazy enough, 100%, again, 100% of apps tested had broken access control issues. So how do you solve it? Well, I'd say look at modern authorization methods and OWASP themselves recommend this.

There are two main types, I'd say, of a modern authorization system. The first is what I mentioned earlier, which is a Google Xanthabar system, where instead of putting roles or reducing everything into an attribute, you do something called Reback or relationship-based access control, where everything is in the form of a relationship. A user has a relationship to a file, a file has a relationship to a folder, and you compute permissions based off of that. There are three ones that I can recommend from their open source, like SpiceDB, OpenFG, and Permify.

I work on SpiceDB, so of course I'm going to have a bias towards that. And the second type is a policy decision point or a policy engine, where your authorization is a logic problem that's served by evaluating a policy. So if something passes that policy, you get a yes. And again, some popular ones include Open Policy Agent, Cedar, and Serbos. I'd say if you have something that has a lot of data and hierarchies and changes frequently, including things like AI and agents, et cetera, go for a Xanthabar system. If you want something where all the information is in the request call itself, I would go for a policy engine.