Apidays Paris 2025 - From AuthN to AuthZ: The Future of Identity By Dick Hardt

Dick Hardt: Well, bonjour. I only know about four other French words. Well, I know that one.

Dick Hardt: I’m excited to be here at API Days in Paris. As I mentioned, my name’s Dick Hardt. I just moved to Paris about a week ago. I’m here until the end of summer, so if anybody here lives in Paris and wants to get together for a coffee or something, please reach out.

Dick Hardt: I’m a serial entrepreneur. I had a couple of tours of duty at both Microsoft and Amazon, led the design of what became OAuth 2.0 and JSON Web Tokens, and I’m currently working on quite a few new specs coming up.

Dick Hardt: So we’re going to talk about the future of identity, particularly around B2B, B2C, Agent Identity, and hopefully have some time for Q&A at the end.

Dick Hardt: So let’s talk about auth. There’s AuthN, authentication. OpenID Connect and SAML are the protocols for that. There’s AuthZ, authorization. Access control and OAuth 2.0. People often conflate them and say, “Oh, I’m going to log in with OAuth,” but that actually isn’t what OAuth was made for.

Dick Hardt: And instead of AuthN and AuthZ, people just say “auth,” as in, “Let’s have auth.” There’s a package called Better Auth. It’s not AuthN or AuthZ. And many of us in the industry have been pedantic about, “Do you mean AuthN or AuthZ?” But I think let’s just call it auth.

Dick Hardt: So enterprise identity and access management, IAM, is acronym soup. There’s SAML, OpenID Connect, your go-to SSO protocol, single sign-on. There’s directory sync. There’s SCIM. And there’s a new protocol I’m going to talk about a bit here, OPC, OpenID Provider Commands.

Dick Hardt: In enterprise SSO, you can go and set it up. It can do all kinds of things. You can make it do anything you want.

Dick Hardt: But the reality is that when you start to deploy the whole thing, it’s complicated. And you’re excited when it just works. Then once it gets working, you say, “Don’t touch it. It’s working now.” Who knows if it’s secure, but it is working.

Dick Hardt: Enterprise customers often have unique, disconnected security requirements: a bunch of things they think, “This is how we need it to be set up.”

Dick Hardt: But often there are gaps in the requirements for building and deploying it, which makes it hard to build and deploy, because you’re having to guess about some things where they had gaps. So then you pick some number, something, to go and set it up at.

Dick Hardt: And SAML, as a framework, has no conformance test. You don’t know, “Hey, is it really doing what it should be doing?”

Dick Hardt: So in SSO, these gaps between systems and processes often lead to some oopsies:

Dick Hardt: some breach, or somebody gets access to something they shouldn’t have access to.

Dick Hardt: As an industry, we’ve wanted to fix those oopsies with IPSIE, Interoperable Profiling for Secure Identity in the Enterprise.

Dick Hardt: In these profiles, they are very opinionated specs: “Here’s how you do it.” That enables you to have conformance testing, knowing something works the way it’s supposed to work. You can have certifications, and then there are different maturity levels for that. There’s session lifecycle one through three, account lifecycle one through three.

Dick Hardt: A little bit more about account lifecycle. If you’re not familiar, in enterprise identity and access management, the goal is that you make a change in the directory and that gets reflected out to all the applications. Offboarding is actually 80 percent of the value: you take somebody out of the directory, and they get taken out of all the apps.

Dick Hardt: SCIM is the most popular way to do account lifecycle now. It’s a REST API. The resource defines a schema, which means that when you’re setting it up to make it work, you’re having to map however your provider manages identity with however the app decided to represent it. It requires manual configuration. It doesn’t have a specified authentication mechanism, so you need to set up an OAuth server for access. It’s very powerful, and it’s designed for complex directory sync, but it’s not widely deployed outside of the Fortune 5000.

Dick Hardt: I saw that as an issue. One of my colleagues, Karl McGuinness, used to be the chief product architect at Okta, and he and I have created a new protocol that we’re standardizing in the OpenID Foundation called OpenID Provider Commands, OPC. These are commands that come from the OP directly to the application. There’s no need for any other auth. It’s a signed token, just like an ID token, and it supports the full ISO lifecycle. It enables you to manage not just delete and active, but also the wide variety of states that an app might want to be able to change.

Dick Hardt: So I see, in the future with IPSIE, instead of just saying, “Hey, do SSO. We’ve got SSO set up,” which is vague and bespoke, IPSIE provides crisp levels. My hope is that, as enterprise customers, people start to say, “I want session level two from IPSIE,” as opposed to, “I want SSO,” or “I want SAML.” It’ll make it a lot easier to deploy. It’ll be secure by default. So with IPSIE, we’ll get fewer oopsies.

Dick Hardt: Similarly, I think OPC can lower the barrier dramatically for doing account lifecycle, particularly around offboarding, so that more organizations have that.

Dick Hardt: Speaking of account lifecycle, a little commercial break on something we’re building at Hello and that we’re going to offer for free: GitHub offboarding, where users link their personal GitHub account to their work account. Then, when they get taken out of the directory, we deprovision them right away from GitHub.

Dick Hardt: It’s one of the big security issues in companies, because people want to use their personal account. So you don’t really know which account to remove. You have to remember to take them out of GitHub when they get let go, and GitHub offboarding automates that for you.

Dick Hardt: Moving on to B2C. There are so many options: passwords, magic links, social login, passkeys, and B2C identity proving who you are online.

Dick Hardt: In the U.S., there’s mobile driver’s license, but no real usage. Each state has its own unique snowflake. In the EU, it’s being used infrequently. The EU is a good decade ahead of the U.S. in this sense, but it’s different in each jurisdiction. Each jurisdiction has its own thing that it has deployed.

Dick Hardt: There’s a hope that eIDAS is going to solve all that, but I have a different view on that. I think that how identity standards proliferate is that you’re going to have yet another way that people can log in in the EU. The Germans are super excited about eIDAS because they don’t have anything that works, so that’ll be what happens in Germany. But in France, and Portugal, where I was just living, they already have systems that are widely deployed. Why are they going to change that?

Dick Hardt: So, the future: digital wallets. There are lots of challenges in adoption. There are variations in different credential standards. They haven’t solved online invocation from a website. There’s no easy way to go from a web page and say, “Hey, I’d like to know something about somebody.”

Dick Hardt: And of course, the EU is concerned about Apple Wallet and Google Wallet, which would be built in and available on the platform, so they have competing wallets. As a developer, it’s going to be really hard to figure out, “How do I get something out of a wallet?” So I don’t think that it’s going to be broadly adopted anytime soon.

Dick Hardt: What about passkeys? In many ways, they’re just yet another way to log in. There are lots of sharp edges in the user experience. As a website, you can’t tell, “Hey, is somebody already registered or not?” So that often leads to extra registrations.

Dick Hardt: Apple, in trying to make them more like passwords, decided to sync passkeys. So instead of being tied to a device, they’re now tied to your keychain. If an attacker gets access to your keychain, they have access to all your passkeys. And it doesn’t solve registration, although they’re working on trying to solve that. So I think it’s just going to coexist with passwords and social login and create some more fracturing.

Dick Hardt: All of you probably came in and went through the API Days website login. You provided your email to log in. It was a magic link, but this was an OTP. You click on it. Autofill ideally shows up. You pick the email you registered with. You give that, and it tells you, “Go check your mailbox.” So you switch over to that app, get the code, which may or may not be able to be copied, then go back to the app, paste it in, and you’re logged in.

Dick Hardt: I’m working on a new thing called EVP, Email Verification Protocol, with some colleagues at Chrome, which gives a magical experience. You go to that same page. You click. Autocomplete and autofill show up. You pick the email you want, and you’re logged in. That really is how it works. We have that running in Hello now, and it’s in Chrome now behind some flags. If you want to try it out, I’m going to do some posts on LinkedIn if you want to try it out yourself and set some things up. I think that’s going to be a nice shift in email verification in the future.

Dick Hardt: You don’t have to take a picture. I’ll give you a QR code at the end.

Dick Hardt: What about social login? You get login and registration. It is the best account protection. The large providers have dozens of engineers working on anomaly detection, trying to build patterns around how you log in, building patterns around how bad guys attack accounts. It’s way better than almost any other site out there, and it works well in web and mobile.

Dick Hardt: The challenge is that people are concerned about privacy and lock-in from big tech, particularly over here in Europe. One of the ways that Hello is looking to solve that is to be an interchange, a privacy layer, an abstraction layer between all the providers and all the apps. So you can just connect to Hello, and then the user can pick any way they want to log in. Unfortunately, there aren’t really any good providers out of the EU yet. I hope at some point we can change that.

Dick Hardt: Next up, Agent Identity. If you’re in a big enterprise, you might roll your own using mutual TLS, SPIFFE, or some workload identity. All of the platforms have rolled out their own proprietary flavor around how you manage Agent Identity.

Dick Hardt: MCP has chosen OAuth 2.1 and dynamic client registration, and now they have client metadata as a way. Agent-to-agent is promoting CIBA, which is a way for the agent to push out a request for the user to be able to say and acknowledge things. That’ll probably work well if you use Okta. And then there’s a new IETF working group called Web Bot Auth that’s using HTTP Message Signatures. I see a number of these things as all related.

Dick Hardt: I also think that how client, server, agent, and MCP server work is very different. In your typical client calling an API, you wrote the client to call one or more particular APIs. You knew ahead of time. It was static. It was preconfigured.

Dick Hardt: With agents, you can give it any MCP server. It figures it all out. There were talks earlier about how you write a good MCP server for an agent to figure out how to call it. But it’s happening at runtime, and you don’t necessarily know who the agent is that’s calling.

Dick Hardt: So many of the assumptions that we had around how we secure our resources are no longer true.

Dick Hardt: One of the controversial statements I recently made online is that I don’t think OAuth 2.0 is a good fit for MCP. You can’t do preregistration. Nobody on the public internet likes dynamic client registration. The only place that has ever been used was inside enterprises.

Dick Hardt: The model is that the agent says, “Hey, here’s who I am,” but how do you really know that it’s that particular server? Even with the client metadata that says a URL, it’s saying, “Here’s my URL,” but any other agent can say, “Hey, that’s my URL.”

Dick Hardt: Traditionally in OAuth, there’s always been a tight coupling of the resource and the authorization server. The resource server would know which scopes the authorization server has, that these particular scopes mean these particular things. That starts to fall down in this new world. It just wasn’t designed for dynamic client and resource relationships.

Dick Hardt: Agents need identity, and I also think they need delegation. You want to know which instance of an agent is making the call, not just that it’s Anthropic or ChatGPT. You want some public, careful, verifiable identity, because it’s not all in the enterprise. There are some services calling from some other part of the internet into your MCP server. So you want something like a URL. We no longer want shared secrets. We want some proof-of-possession authentication where you’re signing things. Then, if you’re signing it, the other side can go back to the URL, get the keys, and know that you are that identity because you signed this.

Dick Hardt: And you want independent delegates. You want each of the little children there, my little baby robots, as you see, to each have their own keys.

Dick Hardt: Another thing with agents is that it’s really driving a requirement to be able to chain and have different layers, where the agent calls an MCP server that calls a resource. It’s rarely that there are only the two parties. So how do you get downstream authorization?

Dick Hardt: There’s also this challenge that, downstream, maybe you need to get a human in the loop to approve something because the agent is making up, “Oh, I want to buy $20,000 of airline tickets.” The MCP server says, “Well, I want to know that the user really wants to do that before I let the agent do that.” How do we get a user in the loop? Access control and audit get really complicated when you start to chain these services.

Dick Hardt: There’s something called Agent Auth, an AAuth proposal that I recently wrote up. This is one of the first times I’m talking about it publicly. I’ve circulated it with a number of people I know, and a number of companies that are trying to solve agent auth, and I got a lot of great feedback.

Dick Hardt: The agent ID is a URL. Everything uses HTTP Message Signatures. There’s a gradient of how you know about the agent that starts from anonymous, where it’s just a bare key, to identified, to authorized, to authorized by a user. User interactions can bubble up the whole chain, and any of the resources can get their own tokens independently and autonomously if you don’t need a user in the loop.

Dick Hardt: It’s a protocol versus a framework, which is what OAuth is, so you can do testing to make sure that it conforms to how it’s supposed to work. And because people conflate access tokens and ID tokens all the time, I’m just calling it an auth token that can do both of those things.

Dick Hardt: So what’s the future of B2B identity? I hope we can get fewer oopsies with IPSIE, and that OPC makes it a lot easier for people to do account lifecycle, so it becomes something that is not just for the Fortune 5000.

Dick Hardt: I don’t think passkeys are going to replace passwords. They’re going to be yet another way to log in. I don’t think mobile digital wallets are going to be commonly used. I don’t think eIDAS is going to become the standard to rule them all. Hopefully email verification becomes easier with EVP, and hopefully the Hello interchange becomes a way for users to get more choice about how they log in.

Dick Hardt: In Agent Identity, agents calling servers is really a new model that didn’t exist before. I don’t think OAuth 2.0 is a good fit. We need auth, not just AuthN or AuthZ. Agent Auth might be one of the answers.

Dick Hardt: Lynn Sun, who is sitting right there, is giving a deeper talk on MCP and auth at 4:30 later today. Go check that out. And with that, I’ll open it up for questions. If you want to follow me on LinkedIn, there’s a QR code for that. I’ll be posting there. I don’t like posting on Twitter as much as I used to, so I post on LinkedIn.

Dick Hardt: Thank you.

Unknown Speaker: Thanks. Questions? Come on. Everybody understood everything? Really? Oh, there’s one here. Yep. I’ll turn to the mic.

Audience Member: The hardball question. Well, maybe just a harder question. If I’m building a new API now, so I have no legacy, how should I think about authentication so that agents can use my service and I become popular?

Dick Hardt: I think the future in B2B SaaS is going to be building agent interfaces instead of web interfaces. How to do all that is still up in the air. I don’t think we know what the right design patterns are yet for agent interfaces. MCP is only a year old. I think we’re on version three or four of the protocol.

Dick Hardt: If you have just a plain API, the existing OAuth framework works fine for that, for authorization.

Audience Member: Okay, thanks.

Unknown Speaker: Any other questions? I think we have one.

Audience Member: I just heard your speech, and it was really good. I just wanted to know, because I wondered: is Hello a new way for identification on the website, or is it like centralization? I don’t know if you understand my question.

Dick Hardt: It is. Hello is a new way to ID on the site, right? Yeah. So Hello acts as an interchange between different ways to log in and the app. We kind of think of it sort of like the Visa for identity.

Dick Hardt: Before Visa, you had to have a relationship with each merchant. You got credit from each merchant. You had to pay cash at merchants or get credit with each merchant. If you had credit, then each month you had to go to each merchant, and each merchant had to come around and collect.

Dick Hardt: Visa became an interchange so that you could just use Visa anywhere that accepted Visa. You reused your credit from your bank, and you had instant credit everywhere else.

Dick Hardt: We view Hello as being that interchange. If you’re building an app, you can connect to Hello. We go and figure out who the user is, whether it’s B2C or B2B.

Dick Hardt: Say you’re building a B2B app. Setting up federation to every one of those enterprises is a big lift every time. With Hello, you just connect to Hello and you’re done. Then we connect to the enterprise and they’re done.

Dick Hardt: It is a central service, sort of like DNS. So we’ve set up Hello itself as governed by a cooperative. And we have some technical innovation internally so that we can’t see the data, and no government can come to us and look at the data. We think that provides a lot of the right privacy, controls, and governance needed for a central service.

Dick Hardt: Thanks for the question that I could answer as an ad.

Unknown Speaker: Thanks. Any other questions? One more.

Audience Member: Great presentation, and thanks for the mention for my talk at 4:30. I have a quick question regarding Agent Auth. I noticed you mentioned Agent Identity is a URL with delegation. What are your thoughts about SPIFFE as the standard for identification? Do you think it could potentially be used in Agent Auth?

Dick Hardt: SPIFFE is at a slightly different layer. SPIFFE enables a workload to get identity from something, and it typically is going to be within an enterprise, closed, trusted environment.

Dick Hardt: Architecturally, Agent Auth will allow a workload to talk to the agent server and get a token that is binding that workload’s SPIFFE key to the identity of the agent server, which would be an external identity. Then that workload could make calls to the rest of the internet, which would know that that one workload is acting as a delegate of that agent server. So yes, it works together.

Audience Member: Could we also think about an agent as a special workload?

Dick Hardt: It is special, but how special, right? I don’t know. I’m going to go and see your talk, and then maybe I’ll learn some things about how you think about how it’s special.

Dick Hardt: In all the large hyperscalers — Google, Microsoft, Amazon — they all are thinking that the agent is special in some ways. I think it’s special in some ways that you want to manage it better. But a lot of things and patterns where we didn’t need to think hard about how access control was managed in workloads, we’re now needing to do what maybe we should have done all along in managing those workloads.

Dick Hardt: So I think a lot of the technologies that exist now need to get more widely deployed than they were previously. Thanks.

Unknown Speaker: Yay, another question.

Audience Member: You talked about using OAuth for MCP. Could you say what the problem is with OAuth? Is it that it’s just impractical, or is it plainly insecure?

Dick Hardt: All the public-facing OAuth servers require preregistration of the client. So the resource owner — say it’s Google, Apple, Flickr — would know which user it was that owned an app. That was in a statically preconfigured model that worked well for client-server.

Dick Hardt: In the agent model, the agent wants to be able to call any MCP server. So it’s impractical for all of the agents to preregister at all of the resources. You want to do dynamic management of registering the client. The challenge with that, then, is that the resource doesn’t really know who’s calling it in any way, which makes it a lot harder to have any enforcement. You don’t know which user is involved.

Dick Hardt: So despite MCP specifying OAuth 2.1 as how you secure your MCP server, I only know of one major service on the internet that has actually deployed dynamic client registration. Almost everybody else works around how that works. When I wrote an MCP server for Hello, I looked at that and I skirted around the model that DCR wanted to do. I just created a fixed agent and squished a bunch of things to simplify it and lower the scope of what could happen, because I didn’t want it to be wide open.

Audience Member: Okay. Thank you.

Unknown Speaker: Thank you. I don’t know if there are any other questions. If not, I think we can catch up with it later. There is one. We have 30 seconds, so this is going to be a really quick question. Go on.

Audience Member: Thank you. I don’t think it will be so quick. But as a follow-up, MCP, as much as I know, is not so dynamic because you need to open the session. You need to tell the agent, “I want to connect to this URL, this URL, and this URL.” The danger is more that, at the end of the day, you can have a lot of different MCP servers and a lot of different MCP clients, but still there is some manual stuff to do. And in that manual stuff, I can use the role to say, “Okay, I connect to this URL with this role. I connect to this URL with this role,” and so on. So for me, it’s not so clear on how to do the authentication today. I think it’s blurry.

Dick Hardt: I disagree heavily. Sure, the agent knows the identity of what it wants to connect to. That isn’t the problem. The problem is that the thing being connected to doesn’t know the identity of who’s calling it, because the agents aren’t all preregistered with the authorization server that’s managing all those resources.

Dick Hardt: And so in the MCP spec, they say, “Oh, support dynamic client registration.” But no one on the public internet supports dynamic client registration. The only place that has ever been used is within enterprises, where you have a controlled environment.

Dick Hardt: The next proposal that’s up is to use client metadata, where there’s a URL that gives you a little sense that maybe that’s the identity of the agent. But there’s no mechanism for the agent to prove it’s that particular identity. It just has a resolvable identifier.

Dick Hardt: So the problem isn’t so much the URL of the MCP server. That works great. I’m happy to chat with you after this in more detail if you want.