Thank you very much, and good morning, everybody. My name is Justin Richer, and I am currently at MongoDB, but I've been in the standards industry for the last couple of decades. And what is now eight years ago, 2018, I made a bold declaration that the future of OAuth is not OAuth.
Today, looking around the landscape, I'm going to alter that a little bit and say that the future of OAuth is beyond OAuth. And today, we're going to go into sort of what that actually means.
Now, the title of this talk, the grammar might have seemed a little odd. That's because I was inspired by the classic Dr. Seuss book, On Beyond Zebra. I absolutely love this book as a child, even though it's a bit of a deep cut from the Dr. Seuss library, because it inspires kids to look beyond the alphabet and find the world that is out there, including letters like this one. And this is a single letter in this book. And the whole idea of this book is look beyond the constraints that the world has set.
Now, further inspired by Dr. Seuss, I asked myself, what if I did this in couplets? But then that was hard. And so I said, fortunately for everybody here, I'm not actually that great of a poet. So I think it's best we just kind of skip that idea. And you can't claim anything about my poetry skills otherwise.
Now, the rest of this talk will not be in rhyme. If I have anything to say about it. All right. So On Beyond Zebra has an absolutely amazing quote. And that it's high time you were shown that you really don't know all there is to be known. The thing that I love about this is that it is saying that, yes, you have the world that's around you, and you may know a lot about that. You may have been taught a lot about that. But there's a lot beyond the edges. So we are today going to take that mindset and look at OAuth. Starting with the fact that OAuth is older than you probably think that it is.
The first draft, the first full public draft of OAuth published December 7th, 2007. That's nearly 20 years ago now that we've been working with this technology. And the web, however, is older than that still. So how did we do things before OAuth?
Well, we just did impersonation. This is how we called APIs. And this kind of makes sense. The way that basic OAuth works is that the user gives a password, and that password goes to a server. And they're usually using a browser. And then the browser is probably going to remember that. The reason that this makes sense is we need to think about how the web started. The web didn't start as an application platform. The web started as document retrieval. That was its goal.
So if you have authenticated document retrieval, then having a password for the document that you're trying to download makes a ton of sense. That also means that when I give my password to my browser or to an application or something in order to do this, that application is effectively impersonating me. Because the server has no idea how to tell the difference between me or the application or anything like that. Because the key equals the person here. The password equals the person. And that works even if the person is not present anymore.
Or if some other application shows up, server can't tell those apart at all. It is all just impersonation baked in. And that is the core problem that OAuth came to solve. That fundamentally is what OAuth came to solve was to solve the password sharing anti-pattern. It also admitted that, hey, APIs are a real thing in websites and the web is an application platform, so we should really start looking at that. And I'm not going to talk a lot about what OAuth is or what it does today. I suggest you check the home edition. And I can recommend a couple of good books on the topic.
But OAuth fundamentally is a delegation protocol that allows a person to say, hey, this software can do something for me. And we do that through use of tokens. And that token can represent that combination of the user and the software to the server, even if the user is not there anymore. Hugely powerful. But we also need to realize that the context that OAuth started in as well. Just like HTTP basic auth started in the world of we're basically doing document retrieval type of stuff, OAuth started in a world where we're trying to get two websites to talk to each other.
Think about what comes with a website. It's got a stable location. It's got an address that it goes to. It's probably got a server and a backend that's going to store things and secrets away from the users. OAuth makes all sorts of assumptions that are so core to the protocol that getting around any of these requires a lot of extension and sort of jumping through some interesting hoops. With OAuth, though, we did take the step in the protocol to say, you know what? It's not really a website that's connected. It's a client. It's generic.
Which means it got genericized and we started to have a whole bunch of different clients. And maybe the user's not even in a browser sometimes. There's all sorts of ways that people started to use this really important and very flexible technology. And this really broke OAuth out of its original very tightly constrained set of things. And so OAuth 2 came along to kind of stretch that out even more. One of the biggest things that OAuth 2 said is that, you know, there are different types of applications. We're going to admit that from the start.
But also, wow, there's a whole lot of different use cases here. And so we really need to build an extensible framework. Because people were already extending OAuth 1, which was never intended to be an extensible framework in the first place. One of the big things that you'll see a lot in OAuth systems is talking about different kinds of clients.
You know, whether you've got a native app or a web app or an SPA or something like that. OAuth 2 goes through lots of different iterations depending on what type of client system and what its capabilities are as you're connecting into this. One of the things that it does is that OAuth 2 invents this thing called a public client. The whole idea with a public client is that you may have many, many copies of the same application that you handed out to people. Those can't all hold a secret in the same way that a website can. So OAuth 2 said, okay, we just won't use secrets. That's totally fine.
And it actually kind of is. In a lot of cases, that works not too bad. And we'll get back to this in a second, though, because this does also create some problems. So one of the other big assumptions that OAuth makes is that since you know the API, you know where the server lives ahead of time. If you're talking to Twitter, well, you're not today anymore. But if you were talking to Twitter, then you're talking to Twitter API. You know where that is.
Well, what if you had the same API deployed in a whole bunch of different places? Like an identity protocol, like OpenID Connect. You would want to be able to dynamically connect all these different things regardless of whether the client and the server knew each other ahead of time. And you want to do that on the basis of what the user says.
Now, if you're a security engineer, this sounds absolutely bonkers. But we have this model in so many different other places that we're totally fine with. Think about email. We can have an arbitrary email client talking to an arbitrary email server, and the way that they connect is through impersonation. We tell the user to give their password to the email client, and it sends it to the server. But the thing is, that trust model works, and it allows for this dynamic connection between these systems.
Because we end up with an end by end matrix of any possible email client can talk to any possible email server, and the power of that standardized protocol that they're speaking, it really shines. OAuth was not designed to solve that case. It was not. And we have added some interesting things to help it do that, including both server discovery and dynamic registration.
Dynamic registration allows us to sort of jump into the space, but it does so in a very sort of specific, deliberate way by kind of just pushing the trust decision to a different web call than the one that starts off the transaction. So the client first shows up and says, hi, I'm a client, and the authorization server says, okay, sure you are. And then from there, it's just standard OAuth. And that is pretty much the basis of the trust of dynamic registration.
So OAuth has been already adapted into a slightly more dynamic world with different kinds of clients than it was originally thought of, and that's worked okay. But now there's AI. AI is changing the conversation in a lot of ways. But it's also bringing up things that sound very familiar. And in fact, a couple of weeks ago, Eve Mailer and I had a session at IIW called all my old problems now have AI in them, but they're still problems. This was a fantastic session, probably my favorite part of IIW this year.
And the thing is, both Eve and I, who's here in the audience, both Eve and I have a lot of experience working outside of what sort of core OAuth does in order to sort of extend this conversation. In particular, two projects that we both worked on was user managed access, which was an extension of OAuth, and it pushed OAuth into some really interesting dynamic use cases. Didn't see a whole lot of deployment except in a few limited circles. And then also GNAP. GNAP likewise was basically what if we did all the things in OAuth but without the wire compatibility restraint? What could we do?
Turns out you can do quite a lot of things. And it has not much deployment except in limited circles. The thing is, these projects taught us as an industry a whole lot of things. And a lot of what I'm seeing today is not that different from what we saw when we were founding UMA and GNAP and all of these extensions of OAuth, right? Here's the funny thing, though. I said at the beginning that I made the bold claim that the future of OAuth is not OAuth.
Well, I was a little bit right. Because OAuth is newer than you think it is. Which is to say that the OAuth that we have today is not the OAuth that we used to have. When I made that statement in 2018, the OAuth that we had, the OAuth landscape that we had does not look like the OAuth landscape that we have today. And that is a really, really interesting thing. Because we keep reinventing this particular wheel. And the good thing about reinventing the wheel is that eventually you get around one. Thanks to Ian for this absolutely wonderful quote. And I will say roundish, right?
So AI stuff, right? Agents are doing all sorts of stuff we don't predict. The world is looking different in a way that it hasn't before. So let's dig into what that means for our software and for how we look at how OAuth works.
Now, if a traditional piece of software does something we don't expect, we call that a bug. And we say that's a problem. If an AI agent says something we don't expect, but we like it, we say that's amazing. This is why we love AI. Underneath this, this isn't really that much different. We still have software doing unpredictable things in both cases. But we're treating it very differently now. And so that changes how we think about trust. How we think about runtime access. All right? I also want to ask the question.
So OAuth tried to solve the problem of I know the API, but I don't necessarily know where it is. What if I don't know the API at all? And that's really where the MCP project comes into play. MCP is a protocol that proxies a request using a JSON RPC wrapper so that an agent can discover all of the bits that it can flip on that API without having to know that API ahead of time. But this creates multiple trust domains.
It's the trust that's being passed from the user to the agent, from the agent to the MCP server, and from the MCP server to the API, and each of these potentially live in a completely different trust domain with different identities, different registration requirements, and so forth. All of these different things are cared about by different parts of the overall system, but they need to work together in order for this thing to actually function and to be secure. And the other funny thing about this is that we can't always predict what that chain is going to look like ahead of time.
We cannot anymore. Predicting the call graph is something that we cannot do.
However, in a few small cases, there are parts of it that we can predict, and that's where OAuth is starting to stretch into some interesting spaces. So cross-app access gives you a way to basically say that, like, okay, so I've got the user and the agent, and I can basically get something over on this side that says the agent can call the MCP server, for example, and then the MCP server can trade that for something that it can use at the API. So we're not passing tokens through.
Really, really good stuff. It keeps trust boundaries in place, and the server gets to know about as much of that chain as we want to divulge to it, because it might care about different parts of that depending on what's going on. So what if we need to talk to the user at runtime? In a world this dynamic, we probably want to get the user involved, and that was one of the innovations that OAuth actually brought to the table, is that since the user's in the browser, we can just ask them if that's what they meant.
Well, that's great, but there's a really big gap here when you've got agents and interstitial servers and stuff like that, but that's where things like elicitation and MCPUI are actually pushing that experience back to the user through these chains so that the user can provide some input, can possibly provide consent. This is an area of ongoing work in the community. I don't think that this has fully landed yet, but we're seeing some really interesting stuff happening there.
The OAuth first party applications extension that's being worked on in the IETF right now also pushes this conversation, because it allows you to basically say, I've got to get the user involved, there might not be a browser, I can do something, and it's really kind of pushing that conversation. Interestingly, it's pushing it in the direction that the GNAP project that I mentioned earlier today also did. So we are seeing a lot of that conversation sort of come back and be applied in these new circumstances. All right.
So what if the software that you're using wasn't the software that was actually making the call, because the software that you're using made software to go do something for it? Right?
It's, like, 20 years ago, that would sound a little bit crazy. But today we call that subagents, right? Agents make other agents. And we can have these dynamic call chains that we can't necessarily predict, but we're probably okay with. The naive thing to do is to just give a set of rights to the top agent, and it just keeps handing that set of rights all the way down. But then we get the exact same impersonation problem, but just hidden from us, the end users, by one extra layer.
If you're working in enterprise systems, like I do in my day job, this is a very, very big problem because you don't know who is actually making the call at any given point and if you're okay with that. And in fact, this makes the famous confused deputy set of problems really, really bad. And we have had subagents decide that the best way to fix the website is to delete the production database and just start over. What's that? Okay. Ah. So in any case, this is not a good thing. Right? I think we can all agree this. So what we really need is a way to attenuate.
OAuth is inventing ways to do that. We published rich authorization requests a few years ago, and that is becoming a very rich way for us to be able to describe that.
That was, again, a backport from GNAP to the OAuth 2 world. Policy languages like Cedar are being wrapped into that. And at every step, we can start to attenuate downward, which means that everybody gets sort of their own set of access rights that's contextual to what that piece might be able to do. So the thing that actually does the decision of, like, how do I speed up the website doesn't have, like, the delete the production database rights in order to effect that change. Because something else needs to hold that larger context.
In order for this to make any sense at all, though, I would argue that we need to have strong attestation of each of these pieces. Because I need to know not only what set of rights is going on, but was it provisioned in a way that I would actually trust and be able to understand? And if you look at this graph and you think this looks a whole lot like workloads, yeah, it does. Like I said, everything old is new again. OAuth is doing a ton of work in the workload space. The whimsy working group in the IETF is seeing some really good work there.
So within a system, within a trust domain, yeah, agents do look a lot like workloads. Crossing a boundary to another trust domain, I'm actually not convinced that they will look like workloads anymore. I'm not sure what they look like yet. I don't think we in the industry have really landed on that yet. But I do think that there's a lot that we can learn from the workload space as we're doing that, as we're stepping into this.
Now, what if the most prestigious part of the system was the client instead of the auth server or instead of the API? Now, what do I mean by that?
Well, in OAuth, the assumption is that you have an API that everybody wants to call. And so the API holds the power and everybody is going to come and bow down before the API and register in order to be able to talk to it. We are now seeing a very stark inversion. Everybody with an API wants to be the API that the agents call. This changes the conversation of how we do registration and trust. And this is where client ID metadata documents in OAuth allow us to invert that registration trust where we actually have a document that the AS will pull.
Now, if the API is the trusted component, why would it ever do that? It wouldn't. But it's because we now trust the client more in some systems. We want the client more in some systems to be an authority. So in conclusion, Ganava already solved a bunch of these problems natively. We did. Years ago. But they were solved in a different context. They were solved for different use cases. I think that there's a lot that we can mine from those projects and other related projects that we can still learn from. Because OAuth was not meant to solve any of these problems. It just full on was not.
But it is solving them. And that's the fascinating thing to me. Because the flexibility of these systems and the ingenuity of people applying these systems in ways that they weren't intended to be and learning from that, that's where we're really going to start to see the innovation. Some of this is being pulled from other projects. Some is being reinvented. And some of it is just brand new. So with that, I really say that the future of OAuth is beyond OAuth.
And truly, everything old is new again. Thank you. Thank you very much, Justin. That was a really awesome presentation. Answering quite a lot of questions I am hearing as well from our endless customers too. It's great to know that there are answers to those. But we have time for one question only. Of course. Yeah. Mike. An observation. OAuth was not designed for login either. That is correct. So yeah. And that wasn't a question. So you can have somebody ask a question. Somebody have an actual question, not just a statement.
Thank you, Mike. When you're talking about the specific context coming with an agent, we were discussing questions about laws-related things, like where you come from, what laws you relate. Are you planning to have ability to negotiate between the agent and whatever they're talking if they're law-even compatible? Because sometimes you just can't. Have you thought about it?
Oh, I've thought about that a lot. Because the N in GAP stands for negotiation.
Again, this is something we built into that protocol because we anticipated use cases where you're not going to know ahead of time exactly what applies until you're actually in that context. And I don't know if we're going to see a lot of that in the OAuth space. We're seeing a little bit of it with first party apps, which sort of gets OAuth out of the way for a few minutes to go do something else and then comes back. I don't know if we will start to see the true point-to-point negotiation in order to address something like that.
That said, legal jurisdiction negotiation is remarkably complicated. And yeah, I have not seen anybody truly tackle that in a satisfactory way to date.
Okay, great. Well, thanks again, Justin. I hope you will be around for people asking further questions. Thank you very much again.
Please, a round of applause. All right. Thank you all.
