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. 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. 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.

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 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 off 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. I'm from Raleigh. This is a little bit about me. It's been great. I came over from Duasio 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. 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 Al and Octa. I did a bit more two years father of two and well yeah it's a little bit of about myself.

So I want to start this with a vision that Al zero 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 Asian era and still stands because at the end of the day is what what we do we deal with identity for past, present and future technology.

Just to give a little bit of what's the challenge. So I said that our vision is just to to free anyone to use any technology but it doesn't mean that all the technologies are the same and all the technologies has the same challenges. It's obvious that agents bring new challenges, new threats. And just to illustrate, this is an updated list of the OASP LFO top 10. So you can see new things that they didn't exist before. So yeah, obviously we need to to solve new problems.

So how we modeled or how we think of agents in our data. So we think 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. Dash 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 talk to other agents.

So 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 this is key. If the agent doesn't know who I am, it can never apply any security or any restriction or any authoration 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 we'll 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 on my behalf as a user.

But sooner or later the agent will try to do something riskier or something that I don't 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 grain. So I need to 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 to also introduce where octa and alto can play or complement each other. So we talked about a user and it could be me, it could be you but eventually will be an employee within an enterprise or a company and in this case the employee is not only acting on his own behalf is also representing the company and in in those cases the company needs also control what exactly those agents that are acting on behalf those employees are doing. So that's where Opta also plays a important part and in the other end Alzero is what we the the capabilities and features that we've implemented I think is where they connect.

Just trying to understand you said the agents need to know who you are. Yes.

Who you are is what as the user and the coder and the one with the permissions is the subject of the the the operation that you're doing. Like 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 is a person a human. Yeah. Yeah. In in the scenario I was talking about.

Is is this what what permission the agent have access to or who has access to the Asian capabilities? I'm not like I don't understand both. Yeah. What does that two here?

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

All right. 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 we are 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 a sync O as part of the O for AI us offering and basically this feature what it does is creates a mechanism and and a protocol for the agent to reach out the user when an operation needs to be approved by the human in in in this flow.

It's seems simple. It it is in essence but well it's security but on it's built on top of client initiated authentication sorry client initiated back channel authentication protocol. It's an ITC specification and it's yeah so in this scenario is the agent that it's 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 with a sync 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. And yeah, I'm going to hand over to Patrick for this one.

Awesome. Yeah, thank you Carlos. And yeah, good question. Thank you both questions. The the token vault as the other kind of like you know major feature we're introducing with this AI more AI targeted AIO 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 oor before right for social providers or in tangent with like other identity providers This makes use cases with agents much much easier.

So we we we have a really fine grained now flow which allows you to exchange tokens. So on on behalf of users so I can you know 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 you know service. So whether that's accessing Slack API or Facebook API or any any other identity you know scoped API and so yeah and we 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 it's it's available and it's secure.

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 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 you know 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 know you don't have a backend which is as you know as secure you're or you're wanting to access an external API in these cases especially like with langraph we we use an access token it's shortlived access token that's simply because langraph stands up an external API there's a langraph protocol around the langraph CLI.

So yeah, in this case like we kind of model that flow whereas like other flows you may just have a native app or a simple Nex.js regular web app traditional web app with your agent running embedded. Then yeah in this case like a refresh token may fits your use case perfectly fine.

And then I think as we're going to talk later, there's also cases where, you know, 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 Ozero. 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 OOTH resource servers or APIs in our platform. So yeah, that's a little bit what's going on here. I've kind of listed some details about token exchange on the slide.

Yes, that just know that the subject token type is kind of type of exchange whether access or refresh. The subject token is your your token the user token be in exchange for the third party token. Let's see. This is a really quick GIF of our interrupt flow with Lingraph. Recently wrote this.

So it just shows kind of you know what the what the mechanism looks like. If the the prompt says you know I need access to my calendar, we have a a Google social provider. We have an interrupt you know as part of our SDK it will feed you back the 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 up access your upstream provider really quite simple in our in our framework now.

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. So and that's that's actually what I'm going to show today.

But yes, the the flow is quite similar and we'll talk more about MCP semantics and you know how we've implemented dynamic client registration and kind of what we have here. These are totally from our teammates. Just trying to pick our favorite slides. And yeah as far as the workshop I think we're planning to just kind of highle high note each section.

If you don't want to work through it, that's okay. 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 Nex.js app. What's nice about Vcel'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 you know it's secure and it's easy to build. You know we we feel quite good about several areas of this the security stack there but yeah I think this is kind of the the rough idea like a lot of typical flows you might see you know 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.

Link: [URL]

And all right. So yeah. Well, while while Patrick is showing and kind of doing the workshop, I'll be available for anyone has a question or a problem with with the workshop itself. Just raise your hand. I will approach you. Awesome. Awesome. Yeah. and then I'll do like 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 welcome is really just around getting your dependencies and getting a a client.

So I guess the first step here we we have a 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 a core IDP provider that you know you you tap into for like upstream API management or upstream identity. So we have this like fictitious stock trade application which looks like this.

And this application basically the idea is is that you know consumers can come here they can access a stock API they can establish identity here but this this application also exposes a stock an API for downstream consumers and downstream agent clients and and additional consumers. So we have a basically a link a federated a linked access with our ODC connection to this to this tenant. So yeah so the first part is really just getting your your client.

I already have a client, but where you would start here is basically just going through Ozer's stack and getting a tenant and starting to get your client developer keys. So we'll add O as the as a subsequent step, but I'll show the like the first step where we just have a really simple agent and then we're we're adding on identity and then authorization. So so yeah these are some prerequisites node PNP standard toys OS 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 like major dependencies After you've created your 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 we're in this step, we're just we're 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 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 open API access key. This is the repo which has the base 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.

Go for agent. Okay. Oops. Okay. Go for it. One, two. Sure. So well yes standard chat box. So at this point when when when you start if you try to do anything other than just regular gen AI questions you will get just the model nothing else but the important part is if we try to to ask the model who who I am that's when the model then says okay I don't know who you are I don't know what they is so I don't I know nothing. The same for in this case this is a downstream of a trade app. If you try to consume data from that trading service like again the chatbot will tell you I know nothing. So let's let's fix that. let's give the chat box awareness first of the service and tools and then also authentication. So let's let's authenticate and let the the agent know who who I am. Okay. So that's okay. Yeah, keep going. I'm going to apply this. So well I will try to sing with Patrick here. Yeah. Um 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 basel 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 all everything stashed. Won't be that easy for you guys, but rest assured that let's run it again. I was going to say rest assured all of the code that's here is is in this stash. So, you don't have to worry about that. So, let's go back to the chat box and let's ask again about prices. You guys want us to try to follow along? You're going to do an overview. Okay. Like, am I supposed to try to keep up with what you're doing? Yeah, that's hard, right? Let's let's let's complete everything, right? Yeah. Okay. Yeah. Good. Good call. You can tell it's the first time we run inspection. Great. Pretty awesome. All right. So let let's let's let's make an actual or let's start with a trading questions or at least get info questions about it. Okay, cool. So, now we've got the chat box connected to the upstream API. Yeah, exactly. In this case it's a public service. It's a public endpoint. So no authentication association was required right let's try so let's move along. There are more info in that page but sorry. Yeah no no no it's okay. I was going to say that let's go back to the kind of important stuff. Okay. All right. 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 is we are going to use token board so basically when when we logged in can you go back the chat box yeah yeah yeah so so far we didn't go through any login process so there is no who I am or anything like so it's just anonymous session so far but at some point we will log in we will log in in the Asian IDE right and but that will give us a relation a trust relationship between us and the Asian alone we need to go beyond that we need to establish a relationship also it's kind of a a three-way thing it's us is the upstream service and the agent so we need to establish this triangle relationship, right? And we do that we will do that through token bot. We will first authenticate the agent that in exchange well issue an ID token and an access token u an access token that basically authorize us to use the agent alone. But we can with token bowl we can use once we establish the third relationship we can use that access token to exchange to exchange it by an upstream access token. Yeah. And that's what token does. What it does is once we connect our upstream app, in this case the demo trade app, Alzero will start storing the refresh token and dealing with the issuance that of the access tokens. So we store the refresh token, we store the the access token for as long as it 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 that's more or less the the graph. Can I yeah jump to so yes you know it's also going to show just adding the basic off for your user and and built and then adding on these these token vault requests. The so SDK code here kind of walks you through like the sign up the terraform all of the tenant setup so that you can start to use these services, right? so that you can access token mold so you can start using identity with providers. This is a very new feature set with some of these features. So you'll you'll notice like in some of our configuration you're enabling a connected accounts feature with our new my account API. You're you know setting up grant types for your client application, your agent application. And you're configuring your OIDC connection. Um so yeah. I don't know if we want to. Let's keep moving and then we can kind of show the tenant. Um but these are kind of the steps we can apply to just add a basic identity. And yeah, I'll turn to you while I'm doing that. Yeah, TDR, all the steps are there. references, links, and everything you need in case you want this to want to do this later or at home. All right. So, let's try. So, the So, at this point, what we're going to do is bring the login button to the agent basically. Just kind of show what that looks like. Yeah. So, route. Yeah. So, so we use ALJ SDK for Nex that provides a middleware not the right one. One second and a wrapper for our routes. You will see. Sorry. One second. Yeah, I think it's that. Oh, it's complaining. Sorry. Conflicts. There we go. Okay, 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. Uh but yeah what is this? So this is the next route for the chat. Yeah. So we've taken the page that yeah has the the chat client. So it's yeah it's just your your standard NexJS page and yeah this is our wrapper which then basically forces login or gives you a redirect. Yeah let's step back a yes and I'm going to add authentication to this agent. Yes. Okay. 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 agent do is I have a existing deployment what additional components you're sharing with me right now. What's my existing deployment? Yeah. And what's out of the box? Yeah. So it's really these wrappers u from the SDK which wrap an endpoint you know whether it's a page route or something else. So yeah and then this is pretty standard with like our next.js JS SDK now we established a session so yeah I'll show login but that's there's 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 like you know the old school zero flows would not have that like you know we 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 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 you know 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. Yeah. Okay. So that was code. I think let me restart. All right. Okay. Let's try it again. Yeah. Run it. No, it didn't. It's it's it's there. Awesome. So I'm gonna sign out and sign in. Yeah. So we sign out. So at this point is up to you want to place a login button or whatever login UX is suits best with with you in this case just to simplify if you try to access the URL it will just prompt you with the login screen right away. So we log in now at this point we are well we it doesn't show but we are logging to the upstream ID. Yes. So using just one credentials and then well at least now it knows that I've got a session and who I am. Let's see. Yeah. Awesome. So it got the profile from the IDP. It load that to the context. Yeah. So now it knows who we are. Yeah. And in this fictitious application like this is also the same identity that's I'm sorry that's linked with the the stock trader sorry yeah this dashboard. So so yeah your identities are now linked between you know 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, okay. 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? Okay. So, it knows who I am, but it doesn't know what I own. What What is that? It doesn't have access to the trading service resources that I own in. So if you go back to the demonstrated app one sec. Yeah this one. Yes. So my balance is 10k. I've got these recent orders. Yeah. Uh so on so forth. So how can we give the agent access to all this data? Yeah. So all right. 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 a user didn't set the explicitly to the agent, hey I I know I 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 are connected the account. So that's when we prompt the user with these extra permissions that the agent needs, these extra scopes, right? And that's when the relationships 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. Yeah. So next I think it's 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 uh 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 how to leverage shared tools and 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 you know TypeScript support. That's also a really nice capability tool organization. So yeah let yeah if you want to keep going I'm going to add the the tools. Awesome. So the same as the same the first step we did we are going to load a well to give the agent a new tool. So far local tools we will get to we will get to into the MCP part later but it is a native tool that it does a simple HTTP request to the service but the tool will have a so we can show yeah sorry so one of the other things that we provide in our SDKs is how we connect this tool with the authentication part and the authentication part. Use the the tools basically again. Yeah. So So can you show the code tool? Yeah. Yeah. No, the tool again the code tool. You show the this one tools or the the get portfolio tool. Oh yeah. Go in uh Yeah. Sorry. Yeah. So at some point we have we create with with a client and in the handler. Yeah. What is that call? So yeah it's just a a get with a include history you know query pram option optional addition there. Pretty straightforward API call once you have a client and a token. But yeah, this the sweet sauce is the you know we can now leverage this get access token for connection really easily on our SDK. So yeah let me show that if you want to yeah it's everything is summarized on this slide 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 in your tenant and that's what does all the dance with the top there I'll say can you show my portfolio sorry so yeah all right so we've got an agent with access to our data now so he knows who I am but also has access to what I am has digital access. Well, it's up to you obviously that the tool implemented but at least yeah I already know exactly what we have. Okay. Okay. So, so we have portfolio tools which is great. I didn't show the scopes but uh yeah rest assured that like I must show the MCP server really quickly. So kind of what we've scaffolded and modeled. And this may help with some of the questions but the yeah here's the MCP server which we've we've modeled as an API. And we have you know scopes around accessing the MCP server. We've kind of modeled those the same way as our 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 in those tools in the meta. That wasn't abundantly clear, but yes, we are representing those as like scoped permissions. How do you create these permissions? Yes. The keyword trade and portfolio these are very application specific. Yes. Yes. Yes. So how would it know what they are mean 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. 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 so how does it identify the meaning of the permission? That's taking it. Yeah, I can. So uh yes, I think I understand but at the end of the day is the upstream service that sets the rules, right? So if you want to access my my my resources, I need an access token with this scope. Otherwise, I would reject your request. And it doesn't it doesn't matter if you're an agent or even a just traditional REST API client. And that rel that you 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 you can tell where do I do that? It's in the connection. Yeah. When you define the connection. Yeah. Yeah. So the 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 like has those scopes modeled around the stock API. So exactly. Yeah. So these scopes I'm getting from that from the from the service. Yes. So this comes out 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 see on on the prom that you saw at the moment that they connect the account. Exactly. So we are here for to simplify we use the same names but it could be different it could be different scopes have it's the translation happens on top of both. Yeah. Yeah. And um yeah, I should also worth mentioning like we model roles differently, right? like around you know 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 FDA we have role based access controls which you can apply around tools as well or around pages but this is more just you know fine grained access around an API so all right let's keep going and this is new yes Yeah, a lot of this is very new. Connections has been around for forever, but the purpose and actually that's the name we chose. The purpose of a connection we create a new one which is talking mode. All right, we're still doing pretty good on time, but yeah, it's okay. Ready to jump in MCP. So yes, any questions so far? Kind of switching topics here. I I wanted to ask similar to your question the scopes will be available you get them from the well-known oids like a hard common way to get these right and you can publicly fetch them and then yes yes yes yes exactly um so yeah that's you've jumped right 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 um yeah, so we've been testing this with a lot of providers recently and recently we just EA our DCR feature like this week. So but yeah, that this flow is a little more involved, right? Because the the MCP server becomes um you know a client of the agent. And we're kind of we're going to show kind of how we modeled that in the Verscell code. And you can see like you know all of the steps there's you know obviously more involved but it's you know 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. Kind of 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 like scope verification on the MCP server itself and how we expose metadata. So yeah, that's exactly what you're alluding to is like we 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 you know creating middleware to verify a JWT we're still you know still a beer token public private key encryption. But yeah, we we reference those libraries. We have a lot of shared libraries for doing these things now. And then yeah it another important mention here is this is where we introduced 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, you know, more independently or how you want to build your stack. But, um, yeah, we've modeled this as a a linked client, which is also a new feature, not zero. Um, so now we can actually link APIs to clients and model them as basically you can think of them as, you know, an agent client or an MCP server client. So, 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 like 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 we've taken this like stock tool portfolio tool from the agent over to the MCP server now. So we can expose it from there as well. And then you know the registration of the tools. And then yeah this is where we create the transport right. So this is where we create this MCP's endpoint and construct the server and yeah that that's where we invoke our middleware and so yeah let me show that and yeah if you want to add anything else feel free yeah so in in this case to an attempt to to show the whole journey we decided to create the NCP as part of this workshop but it could also be that you get your upstream NCP not that you are building an NCP but you still need to authorize to that right so in in in both cases association works so it's not that we wanted to show both ends so that's why there's so many so so much code in in that page it's