Thank you for the kind introduction. Great talk, Alex. We're going to talk today about token-based access control. If you didn't hear, I'm Mike Schwartz. I'm the founder of Gluu. I'm just going to give you sort of a roadmap for this talk. This is my plan. I'll tell you what is this new token-based access control thing. Just why do we need it? Why do we need another access control mechanism? The second half will go into how it actually works. Then at the end, hopefully, we'll have time for questions. I'd like to think of this as a new mental model for authorization.
If you're wondering why there are pigeon guys, I raise pigeons. Pigeons is my theme. My wife told me not to talk during this slide because everyone's going to be watching the animation and no one's listening to me. I remember this from grade school where this is a diagram of the solar system and how contorted the explanations had to get for identity-centric model of the solar system. Heliocentric provided an easier way.
I think that one of my mentors, Alan Karp, IAW legend, said to me, back in the 1970s when he was working with NIST and the government, there were two doors to go through for access management. One was the identity-based. I'm going to get off that because it's too distracting. One door was identity-based access control and the other door was capabilities-based access control. NIST decided to go through the identity-based access control door. I've been thinking about that. My conclusion is that it's time to go back and choose that other door, capabilities-based access control.
I want to tell you why I think that is. I can't do that unless I tell you my appraisal of where we are today and give you some bad news. The bad news is that MFA is a mess. People don't understand the workflows that we're putting them through. Companies have a really hard time rolling it out. As long as we've had two-factor authentication, you'd think it would be going better now, but really it's still quite a challenge. Logout is unsolved. This is one of the existential questions of single sign-on. We can single sign-on, but why can't we single sign-out?
Centralized policy management has been a thing since I started in the business in the late 90s, but it's still more the exception than the rule. The good news is that JWTs have emerged as a ubiquitous token format. Thanks to Mike Jones and others, I think that is real progress that has been made, and we're going to base our solution on that. Why do we need a new access control mechanism? First and foremost, there's more software than people. If you think about every app on your phone having an identity, right away you have probably 20 or 30 pieces of software acting on your behalf.
There's also potentially other agents in the cloud. You've heard the expression, software is eating the world.
Well, there's more software than people now. That's clear. We can't really figure out how to do AI delegation. This is like the holy grail of authorization problems.
So far, there's no clear way to solve this. Although JWTs are a standard, there's a lot of JWT token types. We have also new types of credentials, JWTs coming from wallets, so wallet credentials, wallet assertions. In addition, we have a situation where basically the perimeter has dissolved, and to have zero trust, we need policy evaluation everywhere. We want policy evaluation in the apps, in the gateway, in the IDP, in the backend, in the database.
Finally, we can't forget about disconnected use cases. You might take your mobile app and go somewhere where there's no network, and we still need policy enforcement there. We could do nothing. Why do something now? But I think doing nothing is not really an answer, because the current systems that we have for access control just aren't working. I don't think these older systems are going away, like RBAC, for example, but I think that's a subset of the total authorization challenge that we're facing. There's a movement in Cloud Native to move to declarative infrastructure policies.
It needs to align with that trend. We need declarative policies. The business value, I think, is detecting threats. We need better ways to detect threats, and having centralized authorization allows us to create a decision log that feeds our threat detection engine with important events that we need to know about that happen post-authentication. A lot of mobile apps, like I don't know the last time I logged into my Uber app or my airline app. They don't log me in very often.
If we're not going to log people in very often, then we need more information about what's happening in the app, and better authorization embedded in apps will give us better information to detect anomalies. That's a brief background of why I thought we needed another access control mechanism. Let's go a little bit into what is it actually. Tokens are basically... I didn't think I needed to define this, and I started talking to people about it, and I realized there wasn't really a lot of agreement on what tokens are. I'm using this term pretty broadly as a self-contained signed something.
We have identity tokens that are well-known. The ID token from OpenID Connect. Access tokens can contain identity information. Verifiable credentials may be presented from a wallet. But we have a bunch of other types of JWTs. For example, we have attestations from a passkey. Is this a device-bound key or is this a shared key? We have platform tokens. Google has an integrity API, and they'll say this app hasn't been changed since it was installed on the app, and this device hasn't been rooted. Sometimes the infrastructure platform providers are providing us important information.
Finally, we have enterprise tokens. You might have an enterprise, they have some business reason, they make their own tokens, and those could be also. There's a lot of tokens. Alex mentioned transaction tokens. I think the trend is we're going to see more and more tokens. I'm really excited about what the WMSI group is working on for workload identity. More JWTs are coming down the pipe. When I look at tokens, I see tokens as evidence. In today's world with misinformation and disinformation, we really have a hard time finding truth.
I don't know if tokens are truth, but tokens are evidence of what the truth of the issuer says. There's a lot of token formats out there. If you can't read the little ones, that's because the one we really care about is JWT. Technically, you could say a SAML token, signed XML certificates could also be a token. Potentially, there's other token types, but I'm really focused on JWTs. I put in DSML. That's a joke. I don't know if anyone remembers that even. Directory service markup language. Access control, token-based access control is an access control mechanism which uses one or more tokens.
A bundle of tokens, not one Uber token. That wouldn't be good. We are not talking about these kind of tokens.
Yubikeys, I mean, we call them tokens, but I'm not talking about these kind of tokens. Crypto tokens.
Actually, somebody asked me about NFTs. I don't think so because they're not self-contained. They need to be checked on the blockchain. Do these even exist anymore?
Okay, not reference tokens. They're not self-contained. They need to be introspected. Don't confuse reference tokens with bearer tokens because both value tokens and reference tokens are bearer tokens. We're talking about JWTs here. This is very much like AuthZen. In an AuthZen request, you send principal action resource context.
You say, is this person doing this action on this resource with this context allowed to do this thing? What's the difference with TBAC is that TBAC, instead of saying this person, we're going to say, here's a bundle of tokens.
From that, the PDP can figure out who's the person, who's the piece of software, who's the issuer, which would imply an organization. In my view of the world, the tokens basically provide a number of different entities. That's a big difference. This is actually going back to capabilities-based versus identity-based. What I'm saying here is that we need to get away from basically saying that the subject is a single entity. The capability is the action and the resource together. What's changing or how do I see the requirements for PDPs changing? An old traditional PDP makes decisions.
You send it a request, it makes a decision. I think we need to extend that capability, and we need to add token validation into the PDP. In the past, we'd say, okay, developers, validating token signature is not a big deal. But as we introduce more and more tokens, the ask on developers is getting bigger because now they have to not only validate the signatures, but they have to validate the contents, the expirations, the NBF. They have to understand what's the contents of each type of tokens. There's a new draft called OAuth Status List, which is like a certificate revocations for tokens.
Now developers need to do three things. They need to validate the signature, the contents, and they need to check for revocation. This is a big ask for developers, and I think we need to reduce the cognitive load on developers and say, developers, just give us your tokens. Tell us what capability you want, and we'll give you an answer. What do we tell developers? Because my feeling is that in some of our other top-down efforts around access control, it hasn't been actionable by developers. So in my opinion, we tell developers three things. Define your capabilities.
Define the policies that are required to get that capability. And then submit those policies for review. In the traditional system, what we would ask the developers is, we would say, we're going to send you some roles, and then you need to create some mapping to capabilities. And that created a brittle mapping between identity and capabilities.
So, okay, what are some of the objections? And I realize introducing a new access control mechanism is really a trope, and people love to shoot down new access control mechanisms. It's sort of like what we do. So I'm pre-anticipating some of the objections here. And one that I get all the time is, aren't reference tokens more secure? You'd rather send a reference token over the Internet, for example, maybe, than at JWT.
Auth0 has, in their best practices, they say, do not add sensitive data to the payload. I mean, we're sending it over TLS, but, I mean, isn't it all sensitive? Whatever we're putting in there, you know, it's PII at the least.
Anyway, the JSON payload can be lost downstream. So this is another. We're working on a plug-in for the database. Traditionally, the API connects to the database. So we know the identity of the API. But if we want to make policies about the person or the software that called the API, we have to trust the API to use that or to assert that information. If we have the tokens, we have a cryptographic chain of custody that we can verify.
Okay, this is the second big objection. I couldn't possibly, you know, evaluate policies unless the PDP has the ability to call APIs or connect to a database or something. And my first answer to this is we need to get better at enriching tokens, because the IDP or the authorization server is in a good position to enrich the tokens and give us some of that data that we need.
And also, nothing says that the application, if it needs more data, can't fetch that data itself and put it into the context. It doesn't have to go into the subject. Tokens are going to get too big. This isn't going to work. Our API gateways are going to break. So normal hygiene applies. You need to understand there's more than one way to send a token. You don't just have to send tokens in the headers, although that is a way to send it.
And yes, you want to keep tokens small. And so we have to only send information on a need-to-know basis, basic data minimization. So in a T-back topology, just to give you an example, the mobile app has a PDP, the API gateway has a PDP, the back end has a PDP, database, and the IDP. The IDP needs to know, should I add that scope to that token? And only by having, in a zero-trust environment, every component needs to understand the security and can't trust the other components. So this is how we get to zero trust.
Okay, so some people have asked, like, I don't really need policy enforcement in my mobile app. In an enterprise app, I might have a manager or a finance group, but in my consumer apps, I don't really need it. My first answer to that would be the most important authorization policy is stepped-up authentication. If the user is doing this transaction, do I need to refresh that authentication or maybe do a stronger authentication? So stepped-up authentication is an authorization policy, and so is logout.
The most basic question you can answer as an application developer is should I be displaying data and allowing input from the user? So that's the responsibility of the developer.
And third, there could be entitlements in the app. Maybe you're only subscribed to this service or that service. Even though it's a consumer app, there can still be entitlements.
Okay, good. I made it to the end. So what's the promise? The promise for the future is that with these tools, we can better model the world. We can reduce the cognitive load on developers. We don't want developers to have to be a PhD in OAuth, have a PhD in OAuth or JWT tokens. So we just want to say, developers, you obtained these tokens. Give us what you got. And from a business perspective, we want to detect threats. So we need the decision logs.
When we get a log of every allow and deny decision, then we can look for a lot of denied events as an indication that maybe we need to reauthenticate or there could be an attacker. Detecting threats is the business value. And so making developers more productive is nice. I don't know that business people care that much. Developers care a lot. But preventing attacks, and that is it. And questions? I saw Justin nodding his head a lot in disagreement. I have a question.
Okay, he's not even agreeing with my head nodding, so there we go. Do you have a question, Justin?
Okay, I do. Give us an example or two of when you would have multiple tokens as input to an authorization decision and how you would use or combine them. So if I'm a mobile app or a React app and I've authenticated a user, I actually get back three tokens, an ID token, a user info token, and an access token. And each of those tokens tells me different things. And in the mobile app itself, you say, well, I'm not supposed to pass the ID token downstream, but I'm the mobile app.
I'm the audience of that token, so I have every right to use that token as input to policy about what I should do in my app. But beyond that, I think the attestation from the passkey is really important because I might want to re-authenticate if that's a shared passkey, and so I need to understand the authenticator that was used, not just the federation data. That makes sense. Thank you. Anybody else quickly?
Otherwise, we will proceed. All right, well, thank you, Mike.
Okay, thank you. Thank you.
