Identity for AI Agents - Patrick Riley & Carlos Galan, Auth0

We're talking today about identity for AI agents and how we authorize agents, MCP servers, and the like. We launched a new product actually this week, so that made this presentation fun. I had a major release just a few days ago for several of these features and GAing these.

Additionally, I should probably preface by saying a lot of this workshop material has been repurposed, and our architect, Bobby Scheck, he goes by nickname Siam Shrek,

kind of prepared a lot of this, and we've kind of massaged it into this presentation.

Yeah, so 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 Auth. We're not going deep on FGA, but just know that there is another kind of sub-product, if you will, that's all around role-based access control.

There's an open source project around fine-grained auth, which really extends this feature set, but that's really kind of another talk.

So yeah, that's some of the things we'll be talking. Quick intros. It's my first time at AIE, so thank you, guys. It's been an awesome week already. Learned so much. Yeah, I'm from Raleigh, not actually a Shire, but this is a little bit about me.

And yeah, it's been great. I came over to Auth0 from Red Hat, and I've learned a lot about the identity space in the last four years. I'm going to roll over to Carlos.

Yeah. Hi. Yeah, 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 based in Spain, in Mallorca, if you know the place. It's a beautiful island. I joined Auth0 and Okta a little bit more through the years.

Father of two, and well, yeah, it's a little bit about myself.

So I'm going to I want to start this with a vision that Okta and Auth0 share. This is to free everyone to safely use any technology. And the fun fact about this is it's a vision that precedes the AI agent era and still stands, because at the end of the day, it's what we do.

We deal with identity for past, present, and future technology. And yeah,

it's to give a little bit of

what's the challenge. So I said that our vision is just to free anyone to use any technology, but it doesn't mean that all the technologies are the same and all the technologies have the same challenges. It's obvious that 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 didn't exist before. So yeah, obviously, we need to solve new problems.

So how we model or how we think about agents in Auth0. So

we think, yeah, so far we've seen interactive agents, chatbots, code editors, but this is unlikely the future. We start to see other modalities where the agent doesn't run anymore in an interactive way. Task runners or autonomous agents is something that is very popular these days.

But beyond that, we see a feature where fully autonomous agents can do things either on behalf of the users or maybe just because agents will start to talk to other agents.

So this is how these are four pillars that we believe will cover all these new modalities. The first one is

AI needs to know who I am. So this is key. If the agent doesn't know who I am, it can never apply any security or any restriction or any authorization or authentication, because I'm just an anonymous source or actor in this, and this is important.

The second is, obviously, the agents will be autonomous enough, but it doesn't mean that it will be alone. It will be just doing things on its own. 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 or something that I don't think, as a user, the agent should do on its own without any supervision from my side. So AI can request my confirmation.

And lastly,

AI access should be fine-grained. So I need to give the agent control to access my resources, but not any resource, not any collection or document or anything. It's just it has to be on my hands to what the agent can access and what not.

And just to also introduce where Okta and Auth0 can play or complement each other. So we talk about a user, and it could be me, it could be you, but eventually it will be an employee within an enterprise or a company.

And in this case, the employee is not only acting on his own behalf, he's also representing the company. And in those cases, the company needs also control on what exactly those agents that are acting on behalf of those employees are doing.

So that's where Okta also plays an important part. And in the other end, Auth0 is what we the capabilities and features that we've implemented, I think, is where they connect. Yeah.

Just trying to understand. You said the agent needs to know who you are.

Yes.

Who you are as what? As the user, as the coder, as the one with the permissions?

It's the subject of the operation that you're doing. It could be anything. It could be you as an employee, it could be you as an owner or something, as an administrator or something. But at the end, it's a person, a human

in the scenario I was talking about.

Is this what permission the agent have access to, or who has access to the agent's capability? I don't understand.

Both. Yeah.

What does the who refers to here?

We're sorry. We are definitely touching on both. So yes, let's yes. And time for questions at the end, absolutely. Let's make sure. Thank you.

Thank you.

Thank you.

Allright, so let's get deep on exactly what we are going to present today. We talk about four pillars, not in a particular order, but I'm going to introduce one of the three, which is or 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 Auth for AI agents offering. And basically, this feature, what it does is creates a mechanism and a protocol for the agent to reach out to the user when an operation needs to be approved by the human in this flow.

It seems simple.

It is, in essence, but well, it's security. But it's built on top of client-initiated authentication sorry, client-initiated back-channel authentication protocol. It's an RTC specification. And it's yeah, so in this scenario, it's the agent that is initiating the authentication and authorization.

So the agent is running maybe it could be a long-run autonomous thing, and at some point needs to make a purchase or make something that is flagged as risk. So with Async Auth and 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 agent in form of an access token.

And that access token contains the exact details that the user approved.

And yeah, I'm going to hand over to Patrick for this one.

Awesome. Yeah, thank you, Carlos. And yeah, good question. Thank you for the questions. The Token Vault is the other kind of major feature we're introducing with this more AI-targeted Auth0 release. Token Vault is a new mechanism for persisting your upstream resource refresh tokens.

So I'm sorry, refresh tokens. And you may have used Auth0 before,right, for social providers or in tangent with other identity providers. This makes use cases with agents much, much easier. So we have a really fine-grained now flow, which allows you to exchange tokens on behalf of users.

So I can send my access token or my application's refresh token, whether it's for an API, whether it's for my application. And I can then request scopes for an upstream service. So whether that's accessing Slack API or Facebook API or any other identity-scoped API.

And so yeah, and 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.

Yeah, we've been testing this flow really extensively, but you can kind of get a picture of what is going on under the hood. And yeah, we'll talk more about Token Vault in the shop. It'll make a lot more sense when we get in there.

I do want to kind of highlight a few flows, though, where I mentioned refresh token and access token. 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,right, and you don't have a back end, which is as secure or you're wanting to access an external API.

In these cases, especially like with LangGraph, we use an access token. It's a short-lived access token. That's simply because LangGraph stands up an external API. There's a LangGraph protocol around the LangGraph CLI. So yeah, in this case, we kind of model that flow.

Whereas other flows, you may just have a native app or a simple Next.js regular web app, traditional web app with your agent running embedded. Then yeah, in this case, a refresh token may fit your use case perfectly fine.

And then I think, as we're going to talk later, 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.

So that's kind of the conceptually what we've done at Auth0. We've taken agent, we've kind of modeled it as a client, and we've taken your APIs and kind of modeled them as traditional OAuth resource servers or APIs in our platform.

So yeah, that's a little bit about what's going on here. I've kind of listed some details about token exchange on the slide. Yes, just know that the subject token type is kind of type of exchange, whether access or refresh.

The subject token is your token, the user token being exchanged for the third-party token. And let's see the place. This is a really quick GIF of our interrupt flow with LangGraph. Recently wrote this. So it just shows kind of what the mechanism looks like.

If the prompt says, "I need access to my calendar," we have a Google social provider. We have an interrupt as part of our SDK. It will feed you back the mention that you need to request additional scopes. We then do the token exchange from Token Vault, get you a new access token, and then you can access your upstream provider.

Really quite simple in our framework now. And quickly about MCP, and then we'll dive into the workshop. MCP is very new for us. We just launched a preview, but we've been avidly working on this for quite some time.

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.

And that's actually what we're going to show today. But yes, the flow is quite similar, and we'll talk more about MCP semantics and how we've implemented dynamic client registration and kind of what we have here. These are totally from our teammates, so

just trying to pick our favorite slides. And yeah, as far as the workshop, I think we're planning to just kind of high level, high note each section. If you don't want to work through it, that's OK. You can follow along.

If you want to work through it and you're more hands-on, that's fine too. And yeah, we really, truly appreciate all your feedback. We do have time at the end for questions and all kinds of feedback, so we would love that.

And yeah, this is what we are building today.

Basically, we are building an agent Next.js app. What's nice about Vercel's platform,right, 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.

So that's really powerful, and it's secure, and it's easy to build. We feel quite good about several areas of the security stack there. But yeah, I think this is kind of the rough idea of a lot of typical flows you might see

in the industry. Yeah, so I'm going to yeah, so we can pull it up and get going. So let's see. Yeah, hopefully everybody is able to capture the link. And

allright, so yeah.

Yeah, while Patrick is showing and kind of doing the workshop, I'll be available for anyone who has a question or a problem with the workshop itself. Just raise your hand, and we'll approach you.

Awesome. Awesome. Yeah, and I'll do a quick intro, then kind of showcase what it does, and we'll kind of step through this journey of building that topology. So yeah, the welcome is really just around getting your dependencies and getting

a client. So I guess the first step here, we have a root tenant, an upstream IdP for you. So this is kind of a little more of an enterprise use case. So let's say you have a core IdP provider that you tap into for upstream API management or upstream identity.

So we have this fictitious Stock Trade application, which looks like this. And this application, basically the idea is that consumers can come here, they can access a stock API, they can establish identity here. But

this application also exposes an API for downstream consumers and downstream agent clients and additional consumers. So we have basically a federated, a linked access with our OIDC connection to this tenant. So yeah, so the first part is really just getting your client.

I already have a client, but where you would start here is basically just going through Auth0's stack and getting

a tenant and starting to get your client developer keys. So we'll add Auth as a subsequent step, but I'll show the first step where we just have a really simple agent, and then we're adding on identity and then authorization.

So yeah, these are some prerequisites: Node, PNPN, standard toys, Auth0 CLI. So we use a CLI for a lot of CLI management of our stack. It makes some things easier. We use a combination of Terraform and CLIs in this demo.

Yeah, so that's kind of the conceptual overview and some of the major dependencies. After you've created your client and kind of signed up here, we've got a link to it here, you should be ready to go for spinning up your tenant.

But yeah, I'll talk more about that in step two. So yeah, let's start with the very beginnings here. So in this step, we're building our downstream chatbot. This is a downstream application that we're just spinning up, hasn't connected to anything yet, and we're adding on this upstream provider and adding on access with agents and with tools.

And so yeah, I used OpenAI with my agent, but yeah, you'll need an OpenAPI access key. This is the repo, which has

the base template. I'll give you a branch at the end, which has all of the changes we make in this workshop.

And yeah, so let's take a look at what that looks like.

Oops. OK, go for it.

You want me to?

Sure.

So yes, it's under ChatBox. So at this point, when you start, if you try to do anything other than just regular GenAI questions, you will get just the model, nothing else. But the important part is, if we try to ask the model who I am, that's when the model says, OK, I don't know who you are.

I don't know what day it is, so I know nothing.

The same for in this case, this is a downstream of a trade app. If we try to consume data from that trading service, again, the chatbot will tell you, I know nothing. So let's fix that. Let's give the chatbox awareness, first of the service and tools, and then also authentication.

So let's authenticate and let the agent know who I am.

OK, so that's OK. Yeah, keep going. I'll apply this.

Yeah, so well, I'll try to sync with Patrick here.

Yeah, yeah.

Yeah, this is pretty standard. I think you saw this in several workshops already, just today, and imagine several times in the last weeks. But yeah, we are in the Vercel AI SDKs. We will introduce the Get Stock Price tool,

and later the authentication part. So let's go for the simple thing. In this case, Patrick is cheating because he has everything stashed. It won't be that easy for you guys, but.

Rest assured that.

Yeah, so let's run it again.

It's going to say, rest assured all of the code that's here is in the stash, so you don't have to worry about that.

So

let's go back to the chatbox, and let's ask again about prices.

If you guys want us to try to follow along, you can give an overview, and then we'll do it in short.

Oh, OK.

Like, am I supposed to try to keep up with what you're doing?

Yeah, that's hard,right?

Yeah.

Let's complete everything,right? Yeah, OK. Yeah, good call. You can tell it's the first time we run this section.

Pretty awesome.

Allright, so let's make an actual or let's start with

trading questions or at least get info questions about it. OK, cool. So now we've got the chatbox and the agent

connected to the upstream API.

Yeah, exactly.

In this case, it's a public service. It's a public endpoint, so no authentication as a decision was required.

Right.

Let's try so let's move along. There are more info in that page, but.

Oh, sorry.

Yeah, no, no, no. It's OK. I was going to say that. Let's go back to the kind of important stuff.

OK.

Allright, what happens if we want to read not public data from the upstream service, but personalized data? So data that I, as a resource owner, own. In this case, we are going to use Token Vault. So basically, when we logged in, can you go back to the chatbox?

Yeah, yeah, yeah, yeah.

So far, we didn't go through any login process. So there is no who I am or anything like that. So it's just anonymous session so far. But at some point, we will log in. We will log in in the agent IdP,right?

But that will give us a trust relationship between us and the agent alone. We need to go beyond that. We need to establish a relationship also. It's kind of a three-way thing. It's us, it's the upstream service, and the agent.

So we need to establish this triangle relationship,right? We will do that through Token Vault. We will first authenticate the agent. That in exchange, we'll issue an ID token and an access token, an access token that basically authorizes us to use the agent alone.

But with Token Vault, we can use, once we establish this third relationship, we can use that access token to exchange it by an upstream access token. And that's what Token Vault does. What it does is, once we connect our upstream app, in this case, the demo trade app, Auth0 will start storing the refresh token and dealing with the issuance of the access tokens.

So we store the refresh token. We store the access token for as long as it until it expires. And every time the agent needs to access this data, it runs the refresh token grant to obtain a new access token.

And that is issued back to the agent. So can you yeah, that's more or less the graph.

Can I jump in? So yes, it's also going to show just adding the basic auth for your user and then adding on these Token Vault requests.

So the SDK code here kind of walks you through the signup, the Terraform, all of the tenant setup so that you can start to use these services,right, so that you can access Token Vault so you can start using identity with providers.

This is a very new feature set with some of these features. So you'll notice in some of our configuration, you're enabling a connected accounts feature with our new My Account API. You're setting up grant types for your client application, your agent application, and you're configuring your OIDC connection.

So yeah,

I don't know if we want to let's keep moving, and then we can kind of show the tenant. But these are kind of the steps we can apply to just add basic identity. And yeah, I'll turn to you while I'm doing that.

Yeah, here they are. All the steps are there, references, links, and everything you need in case you want to do this later or at home. Allright, so.

That'sright. So the.

So at this point, what we're going to do is bring the login button to the agent, basically.

Yeah, just kind of show what that looks like.

Yeah, so.

Route.

Yeah, so we use Auth0 SDK for Next.js that provides a middleware.

Yep, not theright one. Hang on a second.

And a wrapper for a route. You will see.

Sorry, one second.

Yep.

I think it's that. Oh, it's complaining. Sorry, conflicts. There we go. OK, there we go.

There we go. Yeah, a huge change. It's intimidating, but it's because it's dealing with the connected account. I think we are in the process of simplifying that in the SDK way more. But yeah.

So what is this one?

So this is the Next.js route for the chat.

Yeah, so we've taken the page that has the chat client. So yeah, it's just your standard Next.js page. And yeah, this is our wrapper, which then basically forces login or gives you a redirect.

Just step back.

Yeah.

Just step back. I have an agent, and I'm trying to add authentication to this agent.

Yes.

OK, where does this fit in?

This is an embedded agent within the Next app. So yes, this chatbot is an embedded agent. We'll show other.

I'll tell you what I'm trying to do is.

External agents.

If I have an existing deployment, what additional components you're sharing with meright now.

Yes.

Back to my existing deployment.

Yeah.

And what's out of the box?

Yeah, so it's really these wrappers from the SDK, which wrap an endpoint, whether it's a PagerOut or something else. So yeah, and then this is pretty standard with our Next.js SDK now. We establish a session. So yeah, I'll show login, but there's really not a lot of magic here.

We are, however, requesting this new connected accounts to see if you have a federated connection. So that's kind of the confusing part here because the old school Auth0 flows would not have that. We wouldn't be requesting upstream providers in many cases or other APIs.

But in this case, yes, we are using a federated provider. And so yeah, it's a little more contrived, I guess. And yeah, we're creating a client there. You can kind of see the OIDC options we're providing, which are specific for OIDC.

And then this connect account endpoint is new. That's going to enable our new connected accounts API for managing all of your accounts. I think that's yeah, so let me show that and kind of yeah, go for it.

OK,

so that was code. I think.

Yeah, let me restart it.

Allright, OK, let's run it again.

Yeah, run it again.

No, it didn't.

It's there.

Awesome.

I'm going to sign out and sign in.

Yeah, so we sign out. So at this point, it's up to you if you want to place a login button or whatever login UX suits best with you. In this case, just to simplify, if you try to access the URL, it will just prompt you with a login screenright away.

So we log in now. At this point, we are well, it doesn't show, but we are logging to the upstream IdP.

Yes.

So using just one credential. And then well, at least now

it knows that I've got a session and who I am.

Let's see. Yeah.

Awesome. So we got the profile from the IdP. It loaded that to the context. So now it knows who I am.

Yeah, and this fictitious application, this is also the same identity that's I'm sorry, that's linked with

the stock trader sorry, yeah, this dashboard. So yeah, your identities are now linked between these applications. You're using an upstream provider, and you'll also see shortly that they'll be linked with your MCP tools as well. So OK,

so we've got identity for we've got login. We've got an embedded agent running locally.

What else do we want to talk about in this step? Are we ready to go on?

OK, so it knows who I am, but it doesn't know what I own. It doesn't have access to the trading service resources that I own in. So if you go back to the demo trader app, one sec.

Yeah, this one?

Yes, so my balance is 10K. I've got these recent orders, so on and so forth. So how can we give the agent access to all this data?

Yeah, so allright.

So the first step is, as we said earlier, we need to connect the two accounts. So even if we are using the same credentials, we still didn't say explicitly, or the user didn't say explicitly to the agent, hey, I know I want you to know who I am, but I didn't give you permissions to access my account yet.

So that's the step you are doing. We have connected the accounts. That's when we prompt the user with these extra permissions that the agent needs, these extra scopes,right? And that's when the relationship is established. So now the agent knows that I have access to this account with that exact permissions, nothing more, nothing else.

Yeah, yep. And yeah, so next, I think, is just adding some tools, which can now leverage this account. So I'm going to jump into portfolio tools. And this is getting into that token exchange. And yeah, now we can start to ask more pertinent queries,right?

We can say, can you view my portfolio? And yeah, we're not going to give you access yet to create orders. That'll be the next pieces. But yes, this kind of shows how our SDK kind of models getting an access token for another connection upstream, how to leverage shared tools in TypeScript.

I think what's really nice here is that these tools can be versatile. They can be shared between whether it's an agent tool or an MCP tool. Hopefully, your framework has TypeScript support. That's also a really nice capability tool organization.

So yeah, yeah, if you want to keep going, I'm going to add the tools.

Awesome. So the same as the same the first step we did, we are going to load and

give the agent a new tool. So far, local tools, we will get to into the MCP part. But this is a native tool that it does a simple HTTP request to the service. But the tool

will have a.

Sorry, one sec.

We can show yeah, sorry.

Yeah.

So one of the other things that we provide in our SDKs is how we connect these two with the authorization part and the authentication part.

Yeah, so here's the tools, basically, again.

Yeah, so can you show the tool?

Yeah, yeah.

No, the tool again, the code tool.

This one tools or.

The Get Portfolio tool.

Oh, yeah, go in.

Yeah,

sorry. Yeah.

So at some point, we create with a client and in the handler.

Yeah, I think it's just a

Git with include history, query param optional addition there. Pretty straightforward API call once you have a client and a token. But yeah, the sweet sauce is we can now leverage this Get Access Token for connection really easily in our SDK.

So yeah, let me show that if you want to.

Yeah, everything is summarized in this line of code. That's what I wanted to show. So our SDK provides this. You provide the connection. In this case, that's the upstream name that is represented in your tenant.

And that's what does all the dance with the token bot.

I'll say, can you show my portfolio? Ooh, sorry.

So yeah, allright, so we've got an agent with access to our data now. So it knows who I am, but also has access to what I own. It has digital access. It's up to you, obviously, that the tool implement it.

But at least, yeah, I'll really know exactly what we have.

OK, so we have portfolio tools, which is great.

I didn't show the scopes, but yeah, rest assured that I'm going to show the MCPs really quickly. So kind of what we've scaffolded and modeled. And this may help with some of the questions, but

yeah, here's the MCP server, which we've modeled as an API. And we have scopes around accessing the MCP server. We've kind of modeled those the same way as our upstream API. So let's see, permissions. We've got scopes around reading trades, reading our portfolio.

And yeah, those are referenced in those tools in the meta. That wasn't abundantly clear. But yes, we are representing those as scoped permissions.

How do you create these permissions?

Yes.

Is that the keyword trade and portfolio? These are very application specific.

Yes, yes.

So how will it know what they are being in the context of the application?

You want to take that one?

What do you mean?

So this app is a stock trading app. So the word trade and portfolio will have very specific meaning here.

Yes.

But I could have another app where the word trade or the word portfolio maybe it's like a project management app. Portfolio would mean something else.

Yeah, but.

So how does it identify the meaning of the permission?

Let me take it again.

Yeah, I can. So yes, I think I understand. But at the end of the day, it's the upstream service that sets the rules,right? So if you want to access my resources, I need an access token with this scope.

Otherwise, I would reject your request. And it doesn't matter if you're an agent or even just a traditional REST API client. And that, as an implementer of the agent, you know that in advance. You know if you are connected to an upstream, you know what's the shape of the request and what's the authorization layer that I need to implement.

You can model your scopes as you want in your local tenant, but at the end of the day, the translation, the scopes to the upstream should be done. So you can tell.

So where do I do that?

It's in the connection.

Yeah.

So when you define the connection.

Yeah,

yeah, so the enterprise connection here to our upstream is here. And yeah, you can kind of see we're requesting those scopes from the upstream tenant. And it also, in this case, has those scopes modeled around the stock API.

Exactly.

Yeah.

So these scopes are getting from the service.

Yes, so these scopes are most likely publicly available, or it's something that is part of the contract between you and the upstream. And that's exactly what the user will going to see on the prompt that you saw in the moment that they connect the account.

Exactly.

So we are here to simplify. We use the same names, but it could be different. It could be different scopes. The translation happens on token bot.

Yeah, yeah, and yeah, I should also worth mentioning we model roles differently,right? Like around personas or other identities, scopes are really around API access,right? So if you're looking to kind of model more around a role, yeah, definitely check out FGA.

We have role-based access controls, which you can apply around tools as well or around pages. But this is more just fine-grained access around an API. So allright, let's keep going.

And this is new?

Yes.

Yeah, a lot of this is very new.

Connections has been around forever. But the purpose and actually, that's the name we chose, the purpose of a connection, we create a new one, which is token bot.

Allright, we're still doing pretty good on time, but yeah, it's OK. Ready to jump in MCP.

Yes, any questions so far? We've been kind of switching topics here.

I wanted to ask similar to your question, the scopes you get available, you get them from the well-known? Oh, he's like a hard.

Yes.

It's a common way to get these scopes,right? You can publicly fetch them, and then.

Yeah, yes.

Yes.

Yes, exactly. So yeah, you've jumpedright into the next flow. And yeah, so we are trying to implement the current spec with MCP now. And that's kind of the next part of this exercise is adding the well-known protected resource metadata endpoint.

And yeah, so we've been testing this with a lot of providers recently. And recently, we just EA'd our DCR feature like this week. But yeah, this flow is a little more involved,right? Because the MCP server becomes a client of the agent.

And we're going to show kind of how we modeled that in the Vercel code. And then you can see all of the steps. There's obviously more involved, but 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.

So yeah, we'll showcase that towards the end here. Yeah, I can probably fire this up if you want.

Yep.

I'm going to see if there's so this kind of show maybe I'll talk through a little bit of this. This kind of shows some of the middleware and how we apply scope verification on the MCP server itself and how we expose metadata.

So yeah, that's exactly what you're alluding to is we advertise the supported scopes when you go to register in that part of the flow. And then yeah, further down, I think it's in the transport when we actually construct so yeah, this is just more helpers.

So it's like creating middleware to verify a JWT. It's still a bearer token, public-private key encryption. But yeah, we reference those libraries. We have a lot of shared libraries for doing these things now. And then

yeah, another important mention here is this is where we introduce this custom API client. Maybe I can show so this is a separate client that we've modeled in this demonstration. You could really create any number of API clients if you want to model them more independently or how you want to build your stack.

But yeah, we've modeled this as a linked client, which is also a new feature, Not Zero. So now we can actually link APIs to clients and model them as basically, you can think of them as an agent client or an MCP server client.

So that's a really nice new feature. Those are now linked, and we have API support for those as well. So yeah, you can see constructing an API client with the MCP server client ID and secret. And yeah, I'll run that in just a second.

I want to see if this so this is, again, like monitoring these shared tools. So we've taken this stock tool, portfolio tool, from the agent over to the MCP server now. So we can expose it from there as well.

And then the registration of the tools. And then yeah, this is where we create the transport,right? So this is where we create the MCPs endpoint and construct the server. And yeah, that's where we invoke our middleware. So yeah, let me show that.

And yeah, if you want to add anything else, we'd love for you.

Yeah, so in this case, I just attempt to show the whole journey. We decided to create the MCP as part of this workshop. But it could also be that you get your upstream MCP, not that you are building an MCP.

But you still need to authorize to that,right? So in both cases, authorization works. So it's not that we wanted to show both ends. So that's why there's so much code in that page. It's just because part of it is the actual MCP server.

So I've unstashed all of the changes in this that I just showed. And yes, this is basically what's going to give us the MCP tools. So yeah, I will start this.

Allright.

So yeah, made the changes to the client. So in this case, in the same Next.js server that the agent is running, it's where the MCP is served. But it's up to you, which that's your architecture. But same concept applied.

Yeah, so I'm going to say.

Yes.

Yeah, go for it.

Yeah.

So if you go back to the chat UI, can you do a prompt injection to tell that now my connection has a different scope and has to be authorized?

You can try that, but it will take no effect

because the fact that you are asking scopes that are not part of the connection would be either ignored or rejected.

So basically, just ignore that.

Yeah, it depends on the upstream. But yeah, so scopes that are not part correct me if I'm wrong, Patrick, but scopes that are not part of the connection can never end up in the access token.

That'sright.

That'sright. So I think our policy, most of the times, is just ignore what we don't recognize. So you will get an access token with valid scopes, but not the one you try to inject.

OK.

And also, I don't think now that you mentioned, I don't think we expose the auth part to the LLM, meaning we expose a tool and we grab the tool, but the authorization happened before the tool execution. So I don't think the LLM will have any influence in what exactly.

But I'm not saying it's not possible because there are many ways to do many things.

But either way, even in our end, anything that we don't recognize shouldn't end up in an access token.

Because you mean that the auth will actually recognize what connections you have before it passes your instruction over to LLM to execute on set,right?

Yes, so when you try to execute the tool, so the tool would say, OK, I need an access token because I need to do an API call. So it's our grapper or our SDK tools that provide this access token to the tool.

It's not the tool on command to the end from the LLM that runs the authorization request. Let me say, it's just old-fashioned code. It's not LLM code.

OK, so now I'm going to show kind of step-by-step the DCR. So yeah, I'm using MCP Inspector, a common tool, and we'll show some others. But yeah, this will kind of just show now we can actually target that MCP server directly running on the same server under /mcp now.

So yeah, and this will show our OAuth flow and DCR happening. So I'm going to hit continue.

So disclaimer, OpenDCR is the same. But it's in early access, and I don't think we will there are some concerns about how this will scale.

Yes.

But there are other specs coming that I think fit better in this scenario.

Absolutely, I agree. But yeah, you can see the protected resource metadata coming back. So we had the well-known endpoint. You can see the scope supported. And then we make a request to the authorization server. That returns more information about our tenant

and additional scopes, how to authorize. So yeah, I'm going to jump through that. And then we get a registration call. So now we're going to get a new client just for testing purposes with the MCP server. So yeah, now we're going to get I believe this is PKCE.

It's our authorization code flow with proof key code exchange. So yeah, it's standard Auth0 flow, but it also works well with MCP. So I'm going to copy this.

OK, so yeah, now it's going to prompt me and give me an authorization code.

And at the end of the line here, we should get an access token, which is great. So now we can access the MCP server with these scopes from anywhere,right? That's the great thing.

So now I'm going to hit connect, and let's see if we can get some tools. Yeah, so

yes, so now we have access to our portfolio. And our identity tools kind of accessing the same upstream stock API. So yeah, you want to add anything here, Carlos, before we go further?

No, any question?

Sorry, I'll ask at the end, yeah.

Sure. Allright, then. OK, so yeah, this is really the most involved part of this flow. I'm going to show the Claude. So I've actually deployed it if you want to play around. And yeah, so that's really the most involved part with MCP, rather.

Yeah, I think we're hitting time. So let's go into the async auth. That's allright.

Allright, OK.

Go for it.

Do you mind still driving the coding so I can talk over?

Absolutely.

Allright, so we said that earlier. The fact that the agent has access to our resources, it doesn't mean that it should do anything in any time without my supervision,right? I said this all the time. We don't want an hallucinating agent buying a stock in the middle of the night without my permission.

What's wrong with that?

Yeah, so that's where

part of the bundle is to provide a simple way and a seamless way to the agent to reach out to the user and get their approval for a risky operation. In this case, we consider place an order, either buy or sell, a risky operation.

It's something that we, as the developers of the agent, define. It's up to us. So in this case, what we are going to do is we will bring

the create order tool, but with some conditions.

Yes.

So those conditions will be that before running the create order tool, we will call backchannel auth. That's the SDK name for the auth async auth. We will obtain an access token that contains exactly what the user is so let me go a step backward.

So we will create this request to backchannel

with the details of the transaction. In this case, it will be exactly the symbol I'm buying or selling, quantity, and the price. For the user to see that in their screen, most likely not out-of-band device, see that and approve that.

And only when that is approved, we will place the order.

Yeah.

For that, in this case, in this sample, we will use Guardian. It's our MFA application. It's out-of-the-box application you can use. You can install and use. But also, we support Guardian SDK in case you want to implement your own.

I'll show the user.

Yeah, so

for the agent to be able to reach out to the user, for this channel in particular, the user needs to be enrolled on MFA. There are several mechanisms to do that. Just for the workshop, we show you kind of the backdoor of it.

But it depends on the UX, how you it could be in sign-up. It could be like a step-up kind of thing. I don't know. It's up to you. But we need to enroll. So you will find it's in the docs, but you will find a way to send an email that contains all the instructions to enroll.

So once we enroll, we can add this little helper here that just basically forwards the auth to our SDK.

Allright, let me undo and reapply here.

Yeah. Am I going faster than you?

No, it's fine. Yeah, it's perfect.

Sorry.

Catching up.

Allright.

One sec.

OK, so in a second, I will show you exactly what we are going to send in this authorization.

We can see.

So I think it was in Auth0 we add the.

Yeah, so here is the.

This.

This is the helper. It's just a grapper just for to grab the errors and all these kinds of things. But basically, it's again, this line of code in our SDK is what we sent and what will run all these steps.

Internally.

Show the tool.

It will wait for the user response. So it's basically an async operation. And when the user responds, the agent can resume.

Sorry,

it's in tools.

Yeah, tools.

Yeah, this one. So yeah, so here we're creating a new client with we're specifying what we need in the authorization details so we can provide that rich authorization request detail when the authorization request comes in.

We're using this custom API client in this case that we've already created. We could create others. But yes, we're creating a custom API client to then perform the backchannel request. And then yeah, in this case, it waits. You could do a number of things.

You could pull.

There's other mechanisms here. But yes, in this case, for simplicity's sake, we wait for the verification. So let me give this a go.

Allright.

Yeah.

OK, so we run the client again. Sorry, the chat box agent.

So we'll go back to here.

Allright.

And so now we can ask to, I don't know, place an order.

What is it? Wayne?

Wayne, yeah, for example.

Fictitious stocks.

Yeah, so in this case. Yeah, go ahead.

I have just a question about the code. I don't know if all this code is checked in. I'm not sure if you have branches.

Yes, yes, yes. Yes, I'm happy to share that towards the do you want me to share it now, or?

Later, just as a follow-up.

Yeah, yeah, yeah.

Yes, we do have a final state branch, yes.

In this case, the agent is instructed to inform the user that this is going to happen. So this is not yet the authorization request. It's just a heads-up that, hey, you're going to receive an authorization notification. Is it OK?

It's just a really silly system prompt line. So you can proceed, then.

Yeah, waiting. Hang on.

One minute here. It should be connected. Let's see. Maybe one minute.

We run this like dozens of times?

Turn that off.

Oh, because you're hot and.

And let's see. Let me try again. Let's see.

Yeah, refresh and try again.

Refresh.

Apart from push notifications, we also support email as a random note. And more channels. We will be implementing more channels to reach out to the user.

Yeah, maybe I need to restart the application server.

Because if I have several users, can I just pre-authorize certain users?

In your engine?

Yes.

Yeah, I mean, I guess it's up to you how you manage this session with your engine.

No, yeah, I want to make sure no one else can engage with.

With the same engine, you mean?

Yeah, or can I be able to pre-authorize the agent for certain access, but also pre-authorize who can use the agent for access to the agent? Just trying to understand what are the different use cases around that.

Yeah, but this is kind of up to you, kind of how you manage your sessions and permissions to access the app as a resource.

OK.

But once you establish that, yes, you can establish any policy that you want at the end. I don't know if I'm following the question. We can chat later, but.

I approved it. So yeah, I had to reconnect here on this network. So let me try one more time.

It did come in.

In this example for this agent, it's saying basically that the agent is asking if it's allowed to go to that website. So I just want to make sure that the agent still authorized to go to that website, but no other websites.

That's what I meant about pre-authentication authorization.

But when you say website, you say the service.

For certain APIs or certain tools, just trying to see if anything can be done as they improve it. Becauseright now, the authentication is happening as interactive.

Yes.

So I'm just saying, can it be?

OK, I see.

Yeah, so this is how I see.

I'm not going to let you access that as a person.

No, no, I understand. I understand now. I understand now. So yeah, I had similar concerns. I'm not in product, sorry. But yeah, so imagine that your interface is not a chat box. It's like a task runner kind of thing.

Exactly.

So I guess what I would implement as an engineer is I would attach my identity, or at least an identifier of the user, the subject, to that task in my database. So I enter the agent. I set up a task.

And I say, OK, I want to, I don't know, find me a good deal, or advise me, or buy Wayne's stocks when it's below 70. It could be a task,right? I think that task is modeled in your system,right?

It has to be modeled somehow. I don't know if it's prompt, an ID of the user. And that's when you establish that. And we use the user. It's the subject. It's what we use to identify if the user has a connection to that account.

So I need this account, this user, to have disconnected.

I understand.

And then I will only.

Can I create a synthetic identity for the agent? Because I want to differentiate if the connection is coming from an agent or coming from the user.

But that's the thing. You are in our auth. Even if an agent performing the request to the service.

Oh, I don't really have.

It's in my recall. So what I need.

But I want to differentiate them. Because if an agent goes rogue, I want to know if the agent goes rogue,right? So I want to know.

Yeah, you can do.

You know what I mean?

Yes, so in that case, because the agent is the client, your access token will have an authorizing party. That's a claim that identifies not the user, but

who the user is delegating the access to. And that's where you can say, OK, this is my ID as an agent. This is my subject. So I can know exactly, OK, this agent is acting on behalf of this user.

And you can run any policy on that that you need.

Yeah.

That's auth. That's nothing new. It's been around forever. But now I understand. I understand, yes.

Also, yeah, I wanted to show kind of logs. And also, just we did show the exchange in the last example for accessing the portfolio. But this is the actual async auth SIBA exchange, which is slightly different in our logs.

But I think it also kind of ties it together really well. And it shows, you know, I'm going to show what an actual token payloaded looks like. Again, fictitious. And these tokens are not going to give you much.

So this is the details I was talking about. We use an extension of auth. It's rich authorization request. It's in the specification. And basically, we can describe exactly what the user is giving consent to.

Yeah.

And that gets recorded in the access log. In a real scenario, most likely, the resource server will want to verify that. But yeah, that's up to the stack. That's out of our but yeah.

I'll show the notification too. So yeah, it looks like so yeah, that's what it looked like on my phone, actually, when I actually connected it to the network and I got a slew of notifications.

One of the challenges with rich authorization requests is that the object is free-form. You can put anything you want. And that complicates things in terms of rendering that request. To solve that, we created a schema. So we support our own schema.

It's flexible enough to give you any opportunity to display anything. But it's known, and it helps for our app in our case, but also in your apps if you are developing yours to render this dynamically. So our guardian app is able to render any details.

And yeah, we provide this schema for you.

Cool. We're good.

Allright.

Awesome. So that's a little bit about our new asynchronous authorization features.

Last piece, and then kind of open up more for discussion. And yeah, I know we'll have a little bit of time. But I just want to quickly show and kind of preface with some of the integrations which we are testing.

This is very beta and shipped very recently. But yeah, this is using that DCR flow. I'm kind of showing how, again, how we did it

with the inspector, but also with Cloud Code or with the chat I'm sorry, the OpenAPI app SDK. So this is just kind of I'm not going to do this now. We're short on time. But obviously, we can deploy this to Vercel.

I'm using an App Stash database, a Redis database for handling the state on the MCP server side.

And yeah, you can get it running pretty quickly on Vercel. So you can take this agent and this MCP server and start sharing these tools. Bring your tools,right, anywhere. So

yeah, so I'm going to show, I guess, just I've got a deployment that I mentioned earlier. I'll target that. And I'll DCR with my deployment. Ironically, it's also linked to the same identity provider. So I'll get back my same information, which is nice.

And then I'll show kind of how in Cloud Code this works. I'm going to skip over ChatGPT app SDK. There is an integration that's starting to work here.

There's some configurations needed. So reach out, and let's talk if you need this today. But yeah, it'll be pretty much readily available in the very near future. So we do have some integrations today that we've tested. But yes, this kind of gives you a rough overview of how you could quickly bring those tools to ChatGPT.

So yeah, I'm going to gloss through that. This is just me showing, like, oh, yes, I've connected it in GPT, and I can access my tools there.

Yeah, let me go ahead. And while if you want to talk to a little bit more of that, I will show kind of getting a new client with my deployed instance and then integrating it in Cloud Code.

Yeah, is this just to showcase that the client, the MCP client, should also run the same policies, auth policies that so all clients should run the same? So should it identify authenticate me and authorize the authorization, the same authorization policies should happen.

So in this case, we embedded the MCP as part of the server. But

well, in this case, Patrick deployed that for us.

So yeah, it's a disconnect.

Same thing we did before.

In this case, this is a production-ish.

Yeah, exactly.

As you can see, it's asking for my authentication.

OK.

And it got an access token with the scopes that we requested.

Allright, so now we're going to pull up Cloud. And so.

And yeah, we can just jump into

Cloud Code. Give it the MCP.

So yep, I've got a command in the README here. And it's in the final.

Allright.

And then yeah, I need to replace the token. I'll say, so in this case, I am going to use my inspector's token. And Cloud does support authentication. However, there is an open issueright now about specifying scopes. So yeah, I'm just going to use my inspector's access token.

But yeah, you'll see that with Cloud. And then Cloud will still initiate. So let me show that.

Unfortunately, the spec is pretty new. And not all the clients implement it the same way.

So yeah, I expect that to stabilize eventually.

There's no copy in this tool, is there?

No.

OK. OK.

Once again, my token is not going to do you much. These are fictitious

trades.

Allright.

OK.

So yeah, same thing as before. You can start asking about what we got in the AppStream service.

It happened.

Is it connected?

Is it connected? OK. Oh, OK. So let me sometimes I have to restart it. I don't know why. OK, now let's see. No. Huh. Yeah, let me try once more here. That did not work. I'm sure. Yeah, I'm not seeing it.

OK, Cloud Add. Yeah, it looked like it was there.

Let's see.

Yeah.

In the meantime, more questions?

Yeah.

You had a question before?

Yeah, I think I get the sort of view when you're an Auth0 customer. Maybe the context here is you're building an app for, let's say, your consumers or something. Then maybe this whole flow will be applicable. I'm thinking, but if you're an Okta tenant, you're using Okta in your workspace.

How do the two work together? Or is this thing also going to be available on the Okta side?

No, I think the idea that got me. I'm going to I don't know exactly. So 100%. But what I think it is, is we are going to create some sort of bridge that you can apply the same policies as Okta as an employee to agents and restrict those accesses to those services as you would do with an employee.

That's where I start your question, more or less?

Kind of, yeah.

Yeah, so.

And also, how the two systems are going to work together. Because this seems like a feature of Auth0, which is, mind the thing.

It is.

Both are owned by Okta, but Okta is a separate product.

Yeah, it is. It is a separate product. But

as far as I know, we work together on both ends.

But yeah, we can connect later if you want. I can dig into docs. Most likely, that's something.

Yeah, I'm not sure what I'm doing wrong here.

We should dig into the

let's see. This Cloud command, don't you have to run it outside the Cloud session?

Maybe.

In the terminal.

Oh, in the terminal. OK, yeah, let's try that.

Anything else? Yeah.

So it seems like if I were to deploy an agent, one way I can start is just to use the user's token on behalf of who the agent is acting as the token for the agent itself. So what do you feel like is the advantage of a distinct agent identity?

What are the features that it has?

So when you say I can just pass so you authenticate the user and just forward the access token to the agent somehow? Or don't do that, please. So the access tokens are meant to first, it will be in terms of operability, it will be cumbersome.

Because access tokens will expire eventually. So at some point, you will need to reach out to the user again. OK, log in and do all the dance again. So how autonomous your agent will be in that scenario. So that's kind of what we try to solve.

So we establish that connection, that relationship. And we take care of this nasty, complex part of refreshing tokens, storing tokens, and yeah, all these scope step up, things like that.

OK, so finally got it working here.

Yeah, I think some of the interactions I might make with the agent are through, say, the chat assistant. And so whenever the agent is taking action, I'm taking action or initiating an action,right? Or are there?

Not necessarily. For example, the example we were talking about before, imagine like a task runner kind of thing. You log in. You have the identity. You have a kind of traditional dashboard where you list your connectable apps Slack, Gmail, Google Calendar, whatever.

And the user does that once, just once. So once these are connected, you give the agent client well, not double quote, it's the agent client access to those apps. So the user, next time they connect to the chat, that's it.

You don't need to run all this thing again. It's already done. The relationship has been established already. So the user will open the chat again. You don't need to do all these connecting scopes, prompts, consent screens. That's it.

That's done.

Eventually, it can die. It depends on the policy of your upstream. Your first tokens may expire. In that case, yes, you will need to deal with, oh, you need to reload again. You do that once, and that's it.

And yeah, so just an update. Was it finally able to syntax or my version of Cloud, I guess. But yeah, I was able to auth and kind of show we went through the authenticate screen. And yeah, now I can access my same tools in a deployed instance.

You can do this with several providers now,right? All of which, any which support as Carlos was saying, like any which support DCR, static client, or pre-configured clients. And then yeah, soon-to-be client ID metadata is the next spec, I believe, that's going to be implemented.

So yeah, you'll have a lot of options to register new clients, new agents, and access your tools.

Yeah, I don't know if there's anything else you want to turn back to.

Questions?

OK.

I think that's it. Questions and feedback, whatever, please reach out. Or yeah.

Yeah, I was going to say, I found the resource that I showed in your workshop. But his question, is there a later branch?

Yes. Yes, absolutely. And let me push that to his repository. And let me show my final state now. And yeah, I'll pull that up and link it here.

Also, I think that's an awesome way to live demo and build this in front of business. There's a lot of.

For the first time.

Yeah, for the first time with a major release this week was like we just shipped this like two days ago. So yeah.

Allright, OK.

But yeah, the final state is in my branch here. Finish state. And that should have all the applied changes. And I think I've tweaked one of the order history tools. But it's pretty straightforward. There's some other tools that are implemented there.

But yeah, it's up to you what you want to implement there. But yeah, let's see. I don't know if I can I can link this in the notes after. And we'll make sure that you have this. I'll probably actually push it to our upstream workshop branch.

So yeah.

Just a little disclaimer, the workshop app, well, it can suffer some disruptions as we develop more things. So yeah, take that into consideration.

Thank you.

Allright.

Allright, thank you. Awesome, thank you.