Building Protected MCP Servers

Talk transcript

1. 0:00

   [upbeat music] Welcome, folks, uh, to the Building Protected MCP Servers session.

2. 0:20

   Uh, I'm Den Delimarsky. I'm a Product Engineer at Microsoft, uh, and member of the MCP Steering Committee.

3. 0:25

   And I'm Julia, and I work in Azure API Management at Microsoft. And the both of us are part of an MCP squad at Microsoft, so I guess that's why we are here.

4. 0:34

   Yeah. Um, so we're gonna... Again, talking about protected MCP servers, and, uh, why, why is this even important? Why is this even a topic? Well, the thing is, when we talk about MCP servers and MCP servers that folks connect to their whatever clients, whether it's Claude Desktop, VS Code, VS, not every server should be open because there's

5. 0:54

   a bunch of different APIs that might require authorization. They're protected. So naturally, your MCP server needs to be able to do the same. Uh, it is super important for remote MCP servers because anybody can access them, and especially if the servers are open to the broad internet, not behind a VPN.

6. 1:10

   Uh, but it's not really relevant for local servers, uh, and mainly because locally you can do a bunch of stuff already because it's just a binary, and we'll get to that in a second.

7. 1:20

   Now, um, if you're building MCP servers and remote MCP servers specifically, one of the things that you're connecting to are likely third-party APIs, uh, whether it's your own or somebody else's, and that API requires user context.

8. 1:33

   That API needs to know who's invoking it because different customers have different permissions. You might have different admin policies. Uh, so while your API does control, through the help of an identity provider, as you...

9. 1:46

   who actually has access, uh, this needs to be somehow exposed to the MCP layer. Uh, and of course your API will act differently depending on the credentials that you give it.

10. 1:56

    If I'm an admin, I get access to a certain set of tools. If I'm somebody that's just a contributor, I get a- access to a, a bunch of different tools.

11. 2:04

    Now, all these things considered, one of the questions I get asked a lot is like, "Well, okay, th- this is all great for remote, but why not local? Why...

12. 2:12

    What's the story for authorization for local servers?" And the answer is kind of simple. Local servers are binaries on the box. They're binaries that run within the context of whatever machine you have.

13. 2:24

    That means that they can do auth in any way you can possibly have. Like, it doesn't need to be auth. You can have credentials that are secrets. You can have certificates.

14. 2:32

    You can have passkeys that are bound to whatever credential you have on the box. Like, it's just... Like, you don't have any constraints whatsoever. Um, that means that any APIs you connect to can also be done, you know, in any way with any of the off-the-shelf libraries.

15. 2:46

    Uh, there's of course special cases here if you do things like remote desktop and all sorts of kind of multi-user scenarios on VMs. Uh, but that's kind of out of scope for MCP.

16. 2:56

    That's something that we've left to implementers. Now, remote servers, let's get back to that. So one of the things that if you've browsed kind of the MCP specs, you might know that we have two different specifications.

17. 3:07

    There's one that is stable, that is March twenty-sixth, uh, and there's one that is draft that we worked very closely with a bunch of security experts to refine. So for the previous specification, the one that is currently marked as stable, MCP required people that are building MCP servers to essentially spin up their own authorization server.

18. 3:28

    That means you are building your own token factory. So if you wanna issue, um, tokens to an MCP client to authorize users, you're the one that has to craft those tokens and manage them and refresh them and sign them.

19. 3:41

    Very complicated. It required people to actually be OAuth experts. Like, if you wanna build an MCP server that does OAuth, you need to understand how Auth works end to end, including to the point of minting those tokens, which is very complicated.

20. 3:55

    So the draft spec that we worked with Anthropic and a bunch of security experts to refine actually does this clean separation between the server, the MCP server, which we call the resource server, and the authorization server.

21. 4:07

    So things like token minting and managing token lifetime actually is not done by the MCP server anymore. It's done by whatever authorization server you're using. So if you're using Okta, Auth0, Entra ID, it doesn't really matter.

22. 4:20

    You can just plug it in into your MCP server, and it's gonna work with the clients that those servers can connect to. And the spec, by the way, is gonna be stable very soon.

23. 4:28

    Now, I wanna hand it off to Julia to talk about the fact that-

24. 4:32

    Not every developer wants to be a security expert, right? Like, we've seen the current draft, now the new one that's about to go live into production. But not everyone, we have some exceptions here, um, who do wanna become security experts, who actually wanna focus on building the remote MCP server, right?

25. 4:50

    You wanna solve a real problem. So this is why the new authorization spec, um, and that's why Den, why a pe- why a bunch of people at Microsoft, we partner- partnered with Anthropic in a security, um, committee to get this new Auth spec out there.

26. 5:08

    So let's see if I paid attention. What are some of the core things that's gonna change now moving forward? First of all, no need to implement the authorization servers anymore.

27. 5:18

    So, um, that means we can now just rather than implementing it from scratch, we can actually ex- at- attend it or append it to our server overall. We can use the standard ways.

28. 5:30

    We only need to reference metadata that are gonna point to our authorization servers, and they are... that's where we're gonna get the token, and then on server side you're gonna have the token, that information here.

29. 5:41

    And all of this is still gonna continue standard OAuth 2.0, so we can actually, as developers, we can rely on all of the libraries that are already out there, all of the services.

30. 5:51

    So it's gonna make our lives a lot, a lot of easier. What does this also include on client side? So on client side, they are now, in a way, responsible for the end-to-end token dance.

31. 6:01

    So this means if the authorization code comes in, um, we can validate it or the client validates, first of all, is the token, has it been, um, acquired successfully?

32. 6:11

    And then on server, it's gonna pass it through to the server, and on server side, which is still very important, um, you're gonna have to make sure if it's been validated correctly.

33. 6:21

    Um, and also, of course, on server side we have to implement, um, the metadata, which we, which I previously just talked about. So again, a lot, a lot of, um, yeah, enhancements now moving forward with the new spec.

34. 6:33

    Saving effort. Saving or sa- saving keystrokes. As developers, they don't need to write a lot of security code because, again, it's ... The risk is higher.

35. 6:40

    Exactly.

36. 6:41

    If you're not a security expert and you start implementing security code, what are the chances that you're gonna get it right on the first shot?

37. 6:46

    100%. And you can start relying on these off-shelf identity providers like Microsoft Entra, Okta, so all of these things, and you, it's just gonna be less work for the developer.

38. 6:57

    But yeah, how does it work in practice, Dan?

39. 6:59

    Yeah, so let, let's talk a bit ... We talked about the new spec and the, for folks that might be a little confused, like, what the heck is the new spec and how exactly it works.

40. 7:05

    So, in a new spec, um, there's a very clear separation of interaction between the MCP client, MCP server, and the authorization server. So, in this case, what happens is your MCP client, like let's say Claude Desktop, is gonna request data from the MCP server.

41. 7:21

    The MCP server at that point, because the MCP client doesn't have any user context yet, is gonna respond back with a standard HTTP 401 saying, "I have no idea who you are and my server is protected."

42. 7:32

    But here's a pointer to something that we call the PRM, the Protected Resource Metadata document, that's embedded in one of the headers in WWW-Authenticate, that's gonna say, "But you can go here and learn more about how to authorize against me, the MCP server."

43. 7:47

    So the MCP client, again, Claude Desktop or VS Code or any other variation, will then talk to the, uh, the, take the PRM, extract from that PRM information about what authorization server it's using, whether it's Okta, Auth0, Entra, Keycloak, it doesn't really matter, and is gonna then ...

44. 8:06

    I, again, I abstracted this out in a very simplistic way, step four, complete flow, but basically the client is gonna do the whole OAuth discovery step by step, go through the dance, get the token, and then it's gonna request data with a token from the server, and the server's gonna return it back.

45. 8:21

    The client is responsible for completing this entire OAuth dance where the server now doesn't actually need to manage tokens. You only need to make sure that you're validating them.

46. 8:31

    I call out th- this thing called the PRM, and the PRM is something hosted by the MCP server that is essentially a JSON document where there's variation. It could be a JSON web token, but for the purpose of this conversation, it's basically a JSON document that says, "Hey, I am this resource.

47. 8:48

    I am this server. And by the way, my authorization servers are the following." And it can give a list of servers. It can specify things like bear method supported as well as scopes.

48. 8:58

    So the client, when it gets this document, knows exactly how to bootstrap the end-to-end authorization flow with OAuth against standard OAuth. You can use, again, off-the-shelf libraries for, for doing this.

49. 9:09

    Uh, let's see it in action in C#, and because we're Microsoft, of course it's gonna be C#. Uh- [laughs] You know. Uh, so, uh, this is currently in a, uh, in a pull request for the C# S- for the official MCP C# SDK, by the way.

50. 9:25

    Uh, to show you just how easy it is to set up an MCP server that is protected by an OAuth provider, by an identity provider, I have essentially an ASP.NET Core application.

51. 9:36

    It could work for any other application, but what I'm doing is all I'm configuring is @authentication to make sure that I'm actually adding Auth to my server. I'm saying that it's using the MCP Auth scheme.

52. 9:48

    I'm adding some validation logic that, again, is built into the framework. Excuse me, we don't see it on the screen. Oh. No. Uh, I see, I see what the problem is.

53. 9:58

    I s- That's in simple C#. Great call-out. Yeah. [laughs]

54. 10:02

    See? It's a fantastic demo. I'm gonna duplicate my screen. That's, that's I think what it's gonna do. There we go. All right. So, say it again. Uh, I'm adding authentication.

55. 10:13

    I'm adding MCP authentication defaults here because it's all baked into the framework. I'm adding some logic to validate the Jot, the token, and this is again, standard embedded into the framework components.

56. 10:26

    Uh, I have some metadata events that are relevant here, and then I'm saying, @MCP. And within @MCP, I'm saying that I'm adding some PRM metadata that I just talked about, which is my server supporting header Auth.

57. 10:39

    And because I'm using Entra ID, can be again Okta, Auth0, I'll specify the metadata and that's it. And then I'll say use authentication, use authorization. There's a lot of boilerplate code here because it's an MCP server that uses, again, the, the stock SDK.

58. 10:53

    But the Auth, that's the complexity. That's all. I needed to add this metadata, and that's kind of it. When I start the server, so it's gonna run locally. Let's take this on.

59. 11:04

    And what I'm gonna do now is I'm gonna go to the browser here, gonna refresh this, and you'll notice that this is the PRM that I talked about. I have a local host server.

60. 11:15

    It says my authorization server is login.microsoftonline.com because I'm using Entra ID. Again, it could be any of them. I define the scopes, and I say that it's using header.

61. 11:25

    That's it. That's what the server says to the client in terms of Auth. Now, I have another instance here that is the client, and the client definition with the C# SDK, again, is super, super simplistic.

62. 11:36

    What I have here is I'm essentially on the client side say, saying that I'm using a generic OAuth provider. There's nothing Microsoft specific here. It's generic OAuth. I'm specifying the client ID for my MCP client, some scopes, and that's kind of it.

63. 11:52

    The rest is standard boilerplate for transport setup as you would with any other client. This client is already set up to connect to my test server, my local server, so if I run this

64. 12:04

    Let's see. Is it gonna connect? It's gonna go ahead and discover the metadata document. It actually went really fast because I'm already authorized here. Perfect demo. Um, but behind the scenes it actually, what it did is it did request the token from Entra ID.

65. 12:21

    It verified, it sent the token to the server, the server verified it, and then invoked a tool that I had on the MCP server and said that there's no alerts, it's a simple weather example.

66. 12:30

    It's nothing too complex here. But the end-to-end developer experience here is extremely simple. Like, we worked very, very hard to not expose any of the security intricacies to developers.

67. 12:40

    You just, that, that's all you do. So C# SDK, it's there. It's, it's in a PR. It's gonna be in production very, very soon. So, uh, Julia, do you wanna talk about VS Code and API Management?

68. 12:51

    Yeah, totally. So okay, we saw this working locally now. We've used the libraries. So what if you now wanna take it to prod- production? I might be biased because I'm part of the Azure API Management team, but I always recommend putting a gateway in between to make it more secure, and actually use it to protect, um, and

69. 13:08

    secure your remote MCP servers. Um, so what I'm gonna show you today is, um, for this we have a public available GitHub repository out there. Um, it's gonna help you and it's gonna spin up an example.

70. 13:21

    Um, and in our example, let's scroll down and go to the overview here, um, we're gonna use Azure API Management in the middle to do and help with, um, authentication.

71. 13:32

    Um, the beauty about this example is it only uses an ACD up. So we wanted to give developers especially, we've heard a lot of, um, complaints about sometimes it takes some time, so we want it to go super fast.

72. 13:44

    So with an ACD up, it will spin up all of the resources. So while I'm doing this and everything is gonna be, um, deploying here, let's talk a little bit about what is gonna be set up under the hood and what's gonna help make our remote MCP server, um, more secure.

73. 14:00

    So as I've mentioned, Azure API Management, Azure Remote MCP Proxy, um, we h- we are hosting it, our remote MCP server on Azure, where we have three tools implemented.

74. 14:11

    We wanna make sure the connection here is secured, and that's where we're gonna use the gateway in between to help us do the dance. And for this, we have an OAuth API that's gonna help the play between our identity provider, in our case it's Microsoft Entra ID, that's gonna help essentially with the login, and also the consent

75. 14:31

    flow here to truly make sure that the, um, connection here is secured to our back end, to our remote MCP server, right? All right, so let's see, um, how the deployment of my resources, resources are looking.

76. 14:45

    I told you it truly only takes maybe five minutes max. Um, it does spin a bunch of other things like, um, an app service plan, log analytics, to make sure that this is truly production ready, and it, um, gives you a way to monitor and also analyze and log it.

77. 15:02

    So I'm gonna copy my endpoint here. Before I'm gonna do something with it, let's just check on Azure API Management side if all of the things have been implemented correctly.

78. 15:10

    Because what we should see now in my APIs tab is we should see the re- the endpoint to my remote MCP server, which is the MCP API, and also the endpoint that's gonna help us handle OAuth.

79. 15:24

    And of course, while the spec evolves, we are also gonna evolve the samples and all of it that comes with it. So let's test it. I'm gonna start MCP Inspector here.

80. 15:33

    Um, let's open MCP s- um, Inspector, um, and provide the URL endpoint. So once I connect, now what I should see is, um, if I click the Connect button here, this is gonna pop up my consent page, right?

81. 15:49

    So it's gonna show the application name. It's gonna make sure that I'm providing the right consent. I'm gonna allow access to it. The first time I'm doing it, I also have to, um, provide the right permissions, so I'm gonna, gonna accept this here.

82. 16:03

    And once I'm back, now you can see I'm actually connected, and now I'm gonna list the tools, and as we talked about it, I currently just have three tools implemented here.

83. 16:13

    All right. VS Code, how does it work actually now in VS Code, for example? VS Code has MCP support as well. I'm just gonna provide the endpoint, um, I'm gonna find a name for my MCP remote server here, which let's call it AI Engineer, and it's gonna add it to my user settings, and immediately it's gonna start

84. 16:33

    running it. And you can see now in VS Code, because they now also support OAuth, they're gonna pop up the window. They're gonna show a notification about, "Hey, let's authenticate towards it."

85. 16:44

    I'm gonna open it, and we're gonna see the same consent page, right? This time with VS Code. Different application name here, where we are again, we're gonna, um, provide our, um, consent.

86. 16:55

    We're gonna allow it, and now back I'm authorized. I'm a- allowed to use it in VS Code Insider. So once that's done, you saw now I have access to the three tools here in VS Code.

87. 17:07

    So let's test this. What it's gonna do in Copilot Studio, uh, Co- uh, GitHub Copilot. Um, so first I'm gonna select and see. Perfect. It's, um, it was able to select my tools, and it's g- um, able to detect these.

88. 17:22

    And now once I start interacting, I s- I have my text prompt here, and just kind of do the Hello Worlds, um, very simple example. Um, GitHub Copilot is now gonna run it.

89. 17:34

    It's gonna detect the tool. Because I've been, am authenticated, it's gonna run it, um, hopefully successfully. Perfect. And now we can also double-check. So if I open the tool calling here, I can see that the output of, "Hello, I'm an MCP tool," has been successfully, um, provided.

90. 17:52

    Um, something new, and I know the world is spinning very, very fast, so... As being part of Azure API Management, we wanna make it easier as well. So we know the similarities between MCP servers and APIs, so one of the latest announcements that we have done is you can now also start transforming your REST APIs into remote

91. 18:14

    MCP servers using our tools, u- using our, um, platform here. And you can configure your already existing endpoint, REST endpoints, into tools that you want to expose to get, like, um, the VS Code.

92. 18:29

    Um, and we're gonna do this all with our platform because we wanna make it easier for enterprise customers, but also developers, to get started with this. So here in my use case, um, I just copied the endpoint that was provided by me, um, by API Management.

93. 18:43

    I'm gonna hit Start and Running. Um, of course, always make sure to implement auth, and that's the beauty about our platform. You can use it for securing it, um, but also for hosting in this case.

94. 18:55

    And now I'm able to also just immediately call it. Um, let's just check if, um, GitHub Copilot was able to detect the MCP server here. Perfect. You can see it right under my Service AI Engineering one.

95. 19:08

    I'm seeing the three tools. That is all based on my REST API in VS Code, and now I'm ready to go and interact with it, um, in VS Code right here.

96. 19:20

    With this being said-

97. 19:22

    Yeah

98. 19:22

    ... um, lots of things are changing in this space. Any, um, good words for the people out there-

99. 19:28

    Yeah

100. 19:28

     ... who wanna get started with remote MCP server then?

101. 19:30

     Yeah. So, uh, there's links on the screen that you can go to. These are the specification documents, uh, that you can learn more about how MCP auth works. We also have a document that we partnered with Anthropic on.

102. 19:40

     It's called Security Best Practices that outline what are the best practices that you should be adopting in your MCP servers, so you wanna make sure that you're not pwned.

103. 19:48

     Uh, very, very important. And then I'll also mention that, uh, starting with VS Code Insiders, we do support the new authorization spec. So you should check it out, download it, install it, give us your feedback, and if anything doesn't work, we have Harold at this conference who can help you debug it.

104. 20:03

     So thank you, folks.

105. 20:04

     Yeah.

106. 20:04

     This was great.

107. 20:04

     Stop by at the booth. [audience applauding]

108. 20:06

     Yeah. [upbeat music]