Full transcript
0:00[Music]
0:15Welcome folks uh to the building
0:17protected MCP servers session. Uh I'm
0:20Den Delmarski. I'm a product engineer at
0:22Microsoft uh and member of the MCP
0:24steering committee. and I'm Julia and I
0:27work in Azure API management at
0:29Microsoft and the both of us are part of
0:31an MCP squad at Microsoft. So I guess
0:33that's why we are here. Yeah. Um so
0:36we're going to again talking about
0:37protected MCP servers and uh why why is
0:41this even important? Why is this even a
0:42topic? Well, the thing is when we talk
0:45about MCP servers and MCP servers that
0:47folks connect to their whatever clients,
0:49whether it's Cloud Desktop, VS Code, VS,
0:52not every server should be open because
0:53there's a bunch of different APIs that
0:56might require authorization. They're
0:58protected. So, naturally, your MCP
0:59server needs to be able to do the same.
1:01Uh, it is super important for remote MCP
1:04servers because anybody can access them
1:06and especially if the servers are open
1:08to the broad internet, not behind a VPN.
1:10uh but it's not really relevant for
1:12local servers uh and mainly because
1:15locally you can do a bunch of stuff
1:16already because it's just a binary and
1:18we'll get to that in a second. Now, um,
1:21if you're building MCP servers and
1:22remote MCP servers specifically, one of
1:25the things that you are connecting to
1:26are likely thirdparty APIs, whether it's
1:29your own or somebody else's, and that
1:31API requires user context. That API
1:34needs to know who's invoking it because
1:36different customers have different
1:37permissions. You might have different
1:38admin policies. Uh so while your API
1:42does control through the help of an
1:44identity provider as you who actually
1:46has access uh this needs to be somehow
1:49exposed to the MCP layer. Uh and of
1:53course your API will act differently
1:55depending on the credentials that you
1:56give it. If I'm an admin I get access to
1:58a certain set of tools. If I'm somebody
2:00that's just a contributor I get access
2:02to a bunch of different tools. Now, all
2:05these things considered, one of the
2:07questions I get asked a lot is like,
2:08well, okay, this is all great for
2:10remote, but why not local? Why what's
2:12the story for authorization for local
2:14servers? And the answer is kind of
2:16simple. Local servers are binaries on
2:20the box. They're binaries that run
2:21within the context of whatever machine
2:23you have. That means that they can do O
2:26in any way you can possibly have. Like,
2:28it doesn't need to be O. You can have
2:30credentials that are secrets. You can
2:31have certificates. You can have pass
2:33keys that are bound to whatever
2:35credential you have in the box. Like
2:36it's just like you don't have any
2:38constraints whatsoever. Um that means
2:41that any APIs you connect to can also be
2:43done you know in any way with any of the
2:45off-the-shelf libraries. Uh there's of
2:47course special cases here if you do
2:48things like remote desktop and all sorts
2:50of kind of multi-user scenarios on VMs.
2:53Uh but that's kind of out of scope for
2:55MCP. That's something that we left the
2:57implementers. Now remote servers. Let's
3:00get back to that. So one of the things
3:01that if you've browseed kind of the MCP
3:04specs you might know that we have two
3:06different specifications. There's one
3:08that is stable that is March 26 uh and
3:12there's one that is draft that we worked
3:13very closely with a bunch of security
3:15experts to refine. So for the previous
3:17specification the one that is currently
3:19marked as stable MCP required people
3:22that are building MCP servers to
3:25essentially spin up their own
3:27authorization server. That means you are
3:29building your own token factory. So if
3:30you want to issue um tokens to an MCP
3:34client to authorize users, you're the
3:36one that has to craft those tokens and
3:38manage them and refresh them and sign
3:40them. Very complicated. It required
3:43people to actually be OATH experts. Like
3:45if you want to build an MCP server that
3:48does OOTH, you need to understand how OT
3:50works end to end, including to the point
3:52of minting those tokens, which is very
3:54complicated. So the draft spec that we
3:57worked with Enthropic and a bunch of
3:59security experts to refine actually does
4:01this clean separation between the server
4:04the MCP server which we call the
4:05resource server and the authorization
4:07server. So things like token minting and
4:09managing token lifetime actually is not
4:12done by the MCP server anymore. It's
4:14done by whatever authorization server
4:15you're using. So if you're using octa
4:17ozero entry ID it doesn't really matter.
4:20You can just plug it in a GMCB server
4:21and it's gonna work with the client that
4:24those servers can connect to. And the
4:26spec, by the way, is going to be stable
4:27very soon. Now, I want to hand it off to
4:30Julia to talk about the fact that not
4:33every developer wants to be on security
4:35expert, right? Like we've seen the
4:37current draft now the new one that's
4:39about to go live into production. But
4:42not everyone, we have some exceptions
4:44here um who do want to become security
4:46experts, you actually want to focus on
4:48building the remote MCP server, right?
4:50You want to solve a real problem. So
4:53this is why the new authorization spec
4:56um and that's why Dan why a PE a bunch
4:58of people at Microsoft we partner
5:00partnered with anthropic in a security
5:04um committee to get this new offsp spec
5:07out there. So let's see if I paid
5:09attention. What are some of the core
5:10things that's going to change now moving
5:13forward? First of all, no need to
5:15implement the authorization servers
5:17anymore. So, um that means we can now
5:21just rather than implementing it from
5:23scratch, we can actually attend it or
5:26append it to our server overall. We can
5:29use the standard ways. We only need to
5:31reference metadata that are going to
5:33point to our authorization servers and
5:36they that's where we're going to get the
5:37token and then on server side you're
5:39going to have the token that information
5:41here and all of this are still going to
5:43continue standard OOTH 2.0. So we can
5:46actually as developers we can rely on
5:48all of the libraries that are already
5:49out there all of the services. So it's
5:51going to make our lives a lot a lot of
5:53easier. What does this also include on
5:55client side? So on client side they are
5:58now in a way responsible for the end to
6:00end token dance. So this means if the
6:02authorization code comes in and we can
6:05validate or the client validates first
6:07of all is the token has it been um
6:09acquired successfully and then on server
6:12it's going to pass it through to the
6:14server and on server side which is still
6:16very important um you're going to have
6:18to make sure if it's been validated
6:20correctly. Um and also of course on
6:22server side we have to implement um the
6:24metadata which we which I previously
6:26just talked about. So again a lot a lot
6:28of um yeah enhancements now moving
6:32forward with the new spec saving effort
6:34saving or saving keystrokes as
6:36developers they don't need to write a
6:37lot of security code because again it's
6:39the risk is higher. Exactly. If you're
6:41not a security expert and you start
6:42implementing security code what are the
6:44chances that you're going to get it
6:45right on the first shot? 100%. and you
6:48can start relying on these offshelf
6:50identity providers like Microsoft Entra,
6:52Octa. So all of these things and you
6:54it's just going to be less work for the
6:56developer. But yeah, how does it work in
6:58practice? Yeah, so let let's talk about
7:00so we talked about the new spec and for
7:02folks that might be a little confused
7:02like what the heck is the new spec and
7:04how exactly works. So in a new spec um
7:08there's a very clear separation of
7:10interaction between the MCP client, MCP
7:12server and the authorization server. So
7:15in this case what happens your MCP
7:17client like let's say cloud desktop is
7:18going to request data from the MCP
7:20server the MCP server at that point
7:22because the MCP client doesn't have any
7:24user context yet is going to respond
7:26back with a standard HTTP 401 saying I
7:29have no idea who you are at my server is
7:31protected but here's a pointer to
7:34something that we call the PRM the
7:35protected resource metadata document
7:37that's embedded in one of the headers in
7:40dubdub authenticate that's going to say
7:41but you can go here and learn more about
7:44how to authorize against me the MCP
7:46server. So the MCP client again claude
7:49desktop or VS code or any other
7:51variation will then talk to the uh the
7:55take the PRM extract from that PRM
7:58information about what authorization
8:00server it's using whether it's octa zero
8:02entra keycloak it doesn't really matter
8:04and it's going to then I again I
8:06abstracted this out in a very simplistic
8:08way step four complete flow but
8:10basically the client is going to do the
8:11whole oath discovery step by step go
8:14through the dance get the token And then
8:17it's going to request data with a token
8:19from the server and the server is going
8:20to return it back. The client is
8:22responsible for completing this entire o
8:25dance where the server now doesn't
8:27actually need to manage tokens. You only
8:28need to make sure that you're validating
8:30them. I call out this thing called a
8:32PRM. And the PRM is something hosted by
8:34the MCP server that is essentially a
8:37JSON document. There's variation. And it
8:39could be a JSON web token, but for the
8:42purpose of this conversation, it's
8:44basically a JSON document that says,
8:46hey, I am this resource. I'm this
8:48server. And by the way, my authorization
8:50servers are the following. And it can
8:52give a list of servers. It can specify
8:54things like bare methods supported as
8:57well as scopes. So the client when it
8:59gets this document knows exactly how to
9:01bootstrap the end to end authorization
9:04flow with all standard O. You can use
9:07offtheshelf libraries for for doing
9:08this.
9:09Uh let's eat an action in C# and because
9:12we're Microsoft, of course, it's going
9:13to be C#. Uh you know, uh so uh this is
9:19currently in a uh in a pull request for
9:21the C# for the official MCP C# SDK. By
9:24the way, uh to show you just how easy it
9:27is to set up an MCP server that is
9:29protected by an OOTH provider, by an
9:31identity provider, I have essentially an
9:34ASP.NET Core application. It could work
9:36for any other application. But what I'm
9:38doing is all I'm configuring is add
9:41authentication to make sure that I'm
9:43actually adding O to my server. I'm
9:44saying that it's using the MCP O scheme.
9:48I'm adding some validation logic that
9:50again is built into the framework.
9:53Oh no,
9:56I see I see what the problem is. I Great
9:59call out. Yeah.
10:02See, it's a fantastic demo. I'm going to
10:05duplicate my screen. That's That's I
10:06think what's going to do. There we go.
10:09All right. So, say it again. Uh I'm
10:12adding authentication. I'm adding MCP
10:14authentication defaults here because
10:16it's all baked into the framework. I'm
10:18adding some logic to validate the jot
10:21the token and this is again standard
10:23embedded into the framework components.
10:25Uh I have some metadata events that are
10:28relevant here. And then I'm saying add
10:29MCP. And within ADM MCP I'm saying that
10:33I'm adding some PRM metadata that I just
10:35talked about which is my server
10:37supporting header O. And because I'm
10:39using entra ID can be again octa zero.
10:42I'll specify the metadata and that's it.
10:45And then I'll say use authentication use
10:47authorization. There's a lot of
10:48boilerplate code here because it's an
10:49MCP server that uses again the the stock
10:52SDK. But the a that's the complexity.
10:54That's all. I needed to add this
10:56metadata and that's kind of it. when I
10:58start the server. So, it's going to run
11:00locally. Let's take this on.
11:04And what I'm going to do now is I'm
11:06going to go to the browser here. Got to
11:08refresh this. And you'll notice that
11:10this is the PRM that I talked about. I
11:13have a local host server. It says my
11:16authorization server is log to
11:18microsoftonline.com because I'm using
11:19entra ID. Again, it could be any of
11:21them. I define the scopes and I say that
11:24it's using header. That's it. That's
11:26what the server says to the client in
11:28terms of O. Now I have another instance
11:30here that is the client and the client
11:33definition with the C# SDK. Again, it's
11:34super super simplistic. What I have here
11:37is I'm essentially on the client side
11:39say saying that I'm using a generic O
11:42provider. There's nothing Microsoft
11:43specific here. It's generic OT. I'm
11:46specifying the client ID for my MCP
11:49client, some scopes, and that's kind of
11:51it. The rest is standard boilerplate for
11:54transport setup as you would with any
11:56other client. This client is already set
11:59up to connect to my test server, my
12:01local server. So, if I run this,
12:04let's see, is it going to connect? It's
12:07going to go ahead and discover the
12:09metadata document. It actually went
12:11really fast because I'm already
12:12authorized here. Perfect demo. Um, but
12:15behind the scenes, it actually what it
12:17did is it did request the token from
12:20Entra ID. It verified it sent the token
12:22to the server. The server verified it
12:24and then invoked a tool that I had on
12:26the MCP server and said that there's no
12:28alerts. It's a simple weather example.
12:30It's nothing too complex here. But the
12:32end to end developer experience here is
12:34extremely simple. Like we worked very
12:36very hard to not expose any of the
12:38security intricacies to developers. You
12:40just that that's all you do. So C# SDK
12:43it's there. It's in a PR. It's going to
12:45be in production very very soon. So uh
12:48Julia, do you want to talk about VS Code
12:51and API management? Yeah, totally. So
12:52okay, we saw this working locally now.
12:54We've used the libraries. So what if you
12:56now want to take it to production? I
12:58might be biased because I'm part of the
13:00Azure API management team, but I always
13:02recommend putting a gateway in between
13:04to make it more secure and actually use
13:06it to protect um and secure your remote
13:09MCP servers. Um, so what I'm going to
13:11show you today is um, for this we have a
13:15public available GitHub repository out
13:17there. Um, it's going to help you and
13:19it's going to spin up an example. Um,
13:21and in our example, let's scroll down
13:23and go to the overview here. Um, we're
13:26going to use Azure API management in the
13:27middle to do and help with um,
13:30authentication. Um,
13:33the beauty about this example is it only
13:36uses an ACD up. So we wanted to give
13:38developers especially we've heard a lot
13:40of um complaints about sometimes it
13:42takes some time. So we wanted to go
13:44super fast. So with an ACD app it will
13:46spin up all of the resources. So while
13:48I'm doing this and everything is going
13:49to be um deploying here. Let's talk a
13:52little bit about what is going to be set
13:54up under the hood and what's going to
13:55help make our remote MCP server um more
13:59secure. So as I've mentioned Azure API
14:02management as your remote MCP proxy um
14:05we we are hosting it our remote MCP
14:08server on Azure where we have three
14:10tools implemented. We want to make sure
14:12the connection here is secured and
14:14that's where we're going to use the
14:16gateway in between to help us do the
14:18dance. And for this we have an oth API
14:21that's going to help the play between
14:23our identity provider. In our case it's
14:25Microsoft enter ID that's going to help
14:28essentially with the login and also the
14:30consent flow here to truly make sure
14:32that the um connection here is secured
14:35to our back end to our remote MCP
14:38server. Right. All right. So let's see
14:41um how the deployment of my resources
14:44resources are looking. I told you it
14:46truly only takes maybe five minutes max.
14:49Um it does spin a bunch of other things
14:51like um an app service plan log
14:53analytics to make sure that this is
14:55truly production ready and it um gives
14:58you a way to monitor and also analyze
15:01and log it. So I'm going to copy my
15:03endpoint here. before I'm going to do
15:05something with it, let's just check on
15:06Azure API management side if all of the
15:08things have been implemented correctly.
15:10Because what we should see now in my
15:12APIs tab is we should see the the
15:15endpoint to my remote MCP server which
15:18is the MCP API and also the endpoint
15:21that's going to help us handle o and of
15:24course while the spec evolves we also
15:26going to evolve the samples and all of
15:28it that comes with it. So let's test it.
15:31I'm going to start MCP inspector here.
15:33Um let's open MCP um inspector um and
15:37provide the URL endpoint. So once I
15:40connect now what I should see is um if I
15:44click the connect button here this is
15:45going to pop up my consent page. Right?
15:49So it's going to show the application
15:50name. It's going to make sure that I'm
15:52providing the right content. I'm going
15:54to allow access to it. The first time
15:56I'm doing it. I also have to um provide
15:59the right permissions. So I'm going to
16:01going to accept this here and once I'm
16:03back now you can see I'm actually
16:05connected and now I'm going to list the
16:07tools and as we talked about it I
16:10currently just have three tools
16:12implemented here. All right, VS Code,
16:15how does it work? Actually, now in VS
16:16Code, for example, VS Code has MCP
16:19support as well. I'm just going to
16:20provide the endpoint and I'm going to
16:23find a name for my MCP remote server
16:26here, which let's call it AI engineer.
16:29And it's going to add it to my user
16:31settings. And immediately, it's going to
16:33start running it. And you can see now in
16:35VS Code, because they now also support
16:38OOTH, they're going to pop up the
16:40window. they going to show a
16:41notification about hey let's
16:43authenticate towards it I'm going to
16:45open it and we're going to see the same
16:47consent page right this time with VS
16:50code different application name here
16:52where we are again we're going to um
16:53provide our um consent we're going to
16:55allow it and now back I'm authorized I'm
16:58allowed to use it in VS Code Insider so
17:01once that's done you saw now I have
17:03access to the three tools here in VS
17:06Code so let's test this what it's going
17:09to do when copilot studio
17:12GitHub copilot um so first I'm going to
17:15select and see perfect it's um it was
17:18able to select my tools and it's um able
17:21to detect these and now once I start
17:24interacting I I have my text prompt here
17:27and just kind of do the hello worlds um
17:29very simple example um GitHub copilot is
17:32now going to run it it's going to detect
17:35the tool because I've been um
17:37authenticated it's going to run it um
17:39hopefully successfully perfect and now
17:42we can also double check so if I open
17:44the tool calling here I can see that the
17:46output of hello I'm an MCP tool has been
17:49successfully um provided
17:52um something new and I know the world is
17:55spinning very very fast so as being part
17:59of Azure API management we want to make
18:01it easier as well so we know the
18:03similarities between MCP servers and
18:06APIs so one of the latest announcements
18:08that we have done is you can now also
18:10start transforming your REST APIs into
18:13remote MCP servers using our tools you
18:16using our um platform here and you can
18:18configure your already existing endpoint
18:22rest endpoints into tools that you want
18:24to expose to get like um VS code um and
18:29we're going to do this all with our
18:30platform because we want to make it
18:32easier for enterprise customers but also
18:34developers to get started with this. So
18:36here in my use case um I just copied the
18:40endpoint that was provided by me um by
18:42API management. I'm going to hit start
18:44and running. Um of course always make
18:47sure to implement O and that's the
18:50beauty about our platform. You can use
18:52it for securing it and but also for
18:54hosting in this case. And now I'm able
18:56to also just immediately call it and
18:59let's just check if um GitHub Copilot
19:02was able to detect the MCP server here.
19:04Perfect. You can see it right under my
19:06service AI engineering one. I'm seeing
19:08the three tools that is all based on my
19:11REST API in VS Code and now I'm ready to
19:15go and interact with it um in VS Code
19:18right here. With this being said, um
19:22lots of things are changing in this
19:23space.
19:25Any um good words for the people out
19:28there who want to get started with
19:29remote MCP server? Yeah, so uh there's
19:32links on the screen that you can go to.
19:33These are the specification documents uh
19:35that you can learn more about how MCP o
19:38works. We also have a document that we
19:39partner with anthropic on that's called
19:40security best practices that outline
19:43what are the best practices that you
19:44should be adopting in your MCP server.
19:46You want to make sure that you're not
19:47pawned. Uh very very important. And then
19:50I'll also mention that uh starting with
19:52VS Code Insiders, we do support the new
19:54authorization spec. So you should check
19:55it out, download it, install it, give us
19:57your feedback, and if anything doesn't
19:58work, we have Harold at this conference
20:01who can help you debug it. So, thank you
20:03folks. It's great. Stop by at the booth.
20:06Yeah.
20:11[Music]