Patrick: We're talking today about identity for AI agents and how we authorize agents, MCP servers and the... Um, we launched a new product actually this week. So, that made this presentation fun. Had a major release just a few days ago for several of these features and ging these. Additionally, I should probably preface by saying a lot of this workshop material has been repurposed and our architect Abbyek, he goes by nicknames Shrek, kind of prepared a lot of this and we've kind of massaged it into this presentation.

Patrick: We're going to cover each of these in depth. some of the core features of this new release whether it's token vault, async off—we're not going deep on FGA but just know that there is another kind of subproduct if you will that's all around role based access control. There's an open-source project around fine grain do off which really extends this feature set but that's really kind of another talk.

Patrick: Quick intros. It's my first time at AIE, so thank you guys. It's been awesome week already. Learned so much. I'm from Raleigh, and I've learned a lot about the identity space in the last four years. I'm going to roll over to Carlos.

Carlos: Yeah. Hi. I'm Carlos. I'm co-host with Patrick for this workshop today. First time in New York, first time in the US. So great so far. Thank you for the welcoming. I'm best in Spain in Mayor if you know the place it's a beautiful island. I joined Auth0 and Okta. I did a bit more two years.

Carlos: So I want to start this with a vision that Auth0 share. This is to free everyone to safely use any technology. And the fun fact about this is is a vision that precedes the AI agent era and still stands because at the end of the day is what we do; we deal with identity for past, present and future technology.

Carlos: Agents bring new challenges, new threats. And just to illustrate, this is an updated list of the OWASP LLM top 10. So you can see new things that they didn't exist before. So far we've seen interactive agents, chat box, code editors but this is unlikely the the future. We start to see other modalities where the agents doesn't run anymore in a in interactive way. Autonomous agents is something that is very popular these days.

Carlos: These are four pillars that we believe will cover all these new modalities. The first one is AI needs to know who I am. This is key. If the agent doesn't know who I am, it can never apply any security or any restriction or any authorization authentication. The second is obviously the agents will be autonomous enough but it doesn't mean that we'll be alone. Eventually they will need to access other services to consume other resources. So AI needs to call APIs on my behalf as a user. But sooner or later the agent will try to do something riskier without any supervision from my side. So AI can request my confirmation. And lastly AI access should be fine grain. It has to be on my hands to what the agent can access and what not.

Carlos: And just to also introduce where Okta and Auth0 can play or complement each other. We talked about a user, but eventually will be an employee within an enterprise or a company. In those cases the company needs also control what exactly those agents that are acting on behalf those employees are doing. That's where Okta also plays a important part and in the other end Auth0 is what we the the capabilities and features that we've implemented.

Carlos: So let's get deep on exactly what we are going to present today. We talk about four pillars. I'm going to introduce how we made possible one of the three which is AI can request my approval. For that we implemented async Auth as part of the Auth0 for AI offering. Basically this feature creates a mechanism and a protocol for the agent to reach out the user when an operation needs to be approved by the human in this flow.

Carlos: It's built on top of Client Initiated Backchannel Authentication protocol. It's an OIDC specification. In this scenario is the agent that it's initiating the authentication and authorization. The agent is running and at some point needs to make a purchase or make something that is flagged as risk. With a simple SDK call it can initiate an authorization request that materializes a notification to the user. The user receives the details of that transaction well structured. The user acknowledges that, approves that and then that approval gets back to the to the agent in form of an access token. And that access token contains the exact details that the user approved.

Patrick: The Token Vault as the other kind of like major feature we're introducing with this AI targeted release. Token vault is a new mechanism for persisting your upstream resource refresh tokens. This makes use cases with agents much much easier.

Patrick: We have a really fine grained now flow which allows you to exchange tokens on behalf of users. I can send my access token or my application's refresh token and I can then request scopes for an upstream service. Whether that's accessing Slack API or Facebook API. We actually persist scopes, we manage lifetimes of tokens, we do a lot of handling there to ensure that your SDK life is very easy and that your agent stays online and it's available and it's secure.

Patrick: As we are digesting each of the agentic frameworks you can kind of see that well it may differ if you're using a single page app or you're wanting to access an external API. Especially like with LangGraph we use an access token. Whereas other flows you may just have a native app or a simple Next.js regular web app with your agent running embedded. Then a refresh token may fits your use case perfectly fine. There's also cases where maybe you have an asynchronous agent accessing other data. We have a new mechanism now called a custom API client which can allow an MCP server for example to access remote data.

Patrick: MCP is very new for us we just launched a preview. But yeah, you can kind of see where we've modeled the MCP server also as a client. And yes, there are cases where agent is a client talking to MCP server which is also a client talking to upstream APIs.

Patrick: We just EA our DCR feature like this week. This flow is a little more involved because the MCP server becomes a client of the agent. It's important because we're actually securing MCP resources and tools and kind of doing it in a granular way but also enabling dynamic registration with many providers. This kind of shows some of the middleware and how we apply like scope verification on the MCP server itself and how we expose metadata.

Patrick: This is what we are building today. Basically, we are building an agent Next.js app. What's nice about Vercel's platform is we can build MCP tools alongside our agent in the same infrastructure quickly. We can then use the agent client to communicate with the MCP server and then leverage the MCP server to talk to third parties.

Carlos: In this case this is a downstream of a trade app. If you try to consume data from that trading service the chatbot will tell you I know nothing. Let's authenticate and let the the agent know who I am. We need to establish a relationship also—it's kind of a a three-way thing—it's us, the upstream service and the agent. So we need to establish this triangle relationship.

Carlos: When an operation needs to be approved by the human, we consider place an order a risky operation. Before running the create order tool we will call back channel Auth. The user receives the details of the transaction in their screen, most likely out of plan device, see that and approve that and only when that is approved we will place the order.

Patrick: I wanted to show how in Claude code this works. Unfortunately, the spec is pretty new and not all the clients implemented the same way. But you'll have a lot of options to to register new clients, new agents, and access your tools.