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 AuthZ, and the story behind this talk is it's actually pretty funny. A long time ago, I released a YouTube video called, well, Don't use JWTs for authorization. Yes, I know I have the very YouTube face in the thumbnail, et cetera. 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 not, you know, sometimes people on the internet can be not so nice because I got a lot of comments like this about, you know, 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 read the RFC 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. And 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, you know, some stuff about an algorithm type, et cetera, and the signature, which is usually a cryptographic signature. So 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, et cetera, 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 OAuth2 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 and 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's 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 the fact that Lex has permissions in this token, Lex attempts to read this document and can see it. And chaos ensues.

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. 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, and this has actually plagued GitHub's REST API for many years, if you have ever used it. In our day and age, we really look for fine-grained authorization.

You can't scale your scopes to fine-grained permission. Scopes are too broad. 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, and this has actually plagued GitHub's REST API for many years, if you have 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. So for instance, issue slash AuthSet slash SPICEdb slash something slash 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. I mean, you can just Google this and you'll see people facing this problem.

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.

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 is 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 body. They make a list of top 10, top 10 security risks for web apps. 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?

There are two main types, I'd say, of a modern authorization system. The first is what I mentioned earlier, which is a Google's Zanzibar 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. So 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 Permafy. 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, CDER, and CERBOS. 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 Zanzibar system. If you want something where all the information is in the request call itself, I would go for a policy engine.

The idea, of course, is you're trading something that is relatively simple, like a JWT, and that is stateless, to something that might be a little more complex to implement at first, but you're getting correctness, flexibility, and most importantly, security, which I cannot stress this enough is so important right now. There are times you can use JWTs when you have a one-time non-revocable grant, like say an email verification link or a download link that expires in a day or whatever. But for production use cases like something long-lived, an app authorization decision, or anything fine grained, I would absolutely avoid using JWTs.

Now I know you have many questions about things like refresh tokens and storing things locally and all of that. I don't have the time to cover that, but that first link I put up there, which has this flow chart, will cover all your questions about using JWTs for fine-grained permissions. A couple of other things you can also read to learn more about this topic. I'd love to connect with you on LinkedIn and I hope you enjoy the rest of the conference. And remember, don't use JWTs for fine-grained permissions. Enjoy and have a great day. Bye.