Remote MCP servers need authorization because they can be reached by anyone and may call APIs with user-specific permissions.
2
The newer MCP authorization design separates the MCP server from the authorization server, so developers can use existing OAuth providers instead of minting and managing tokens themselves.
3
Azure API Management can protect remote MCP servers, expose REST API operations as MCP tools, and connect them to clients such as MCP Inspector and VS Code.
Summary
Den Delimarsky and Julia Kasper explain why remote MCP servers need a standard authorization flow. A server may call APIs that behave differently for administrators and contributors, so it needs user context and permission checks. They compare this with local servers, which run as binaries on a user's machine and can use whatever credentials or authentication libraries the implementer chooses. The newer MCP authorization specification separates the MCP server, treated as the resource server, from the authorization server. Clients discover authorization details through protected resource metadata, complete the OAuth flow, and send the resulting token to the MCP server. The server validates the token but does not mint or manage it. A C# example shows the framework configuration, followed by a deployment using Azure API Management as a gateway. Julia connects the protected server to MCP Inspector and VS Code, then demonstrates exposing REST API operations as MCP tools. The talk ends with links to the specification and security best practices.
Delimarsky says MCP servers are connected to clients such as Claude Desktop, VS Code, and Visual Studio, but not every server should be open. Remote servers are especially exposed when they are available on the public internet rather than behind a VPN. They may call third-party or internal APIs that require user context. An administrator and a contributor can receive different tools or permissions, so the MCP layer has to carry the user's authorization through to the API.
Local MCP servers have fewer authorization constraints
Local servers run as binaries on the user's machine. Because of that, an implementer can use many forms of authentication, including secrets, certificates, passkeys, or any available off-the-shelf library. The APIs called by the local server can use those credentials directly. Delimarsky mentions remote desktop and multi-user virtual machine cases as special situations, but leaves those outside the MCP scope for implementers to handle.
The newer specification separates resource and authorization servers
Under the earlier stable specification, an MCP server builder had to run an authorization server and handle token creation, signing, lifetime, and refresh. Delimarsky describes this as requiring developers to understand OAuth end to end. The newer draft, developed with Anthropic and security experts, separates the MCP server as the resource server from the authorization server. Providers such as Microsoft Entra ID, Okta, and other identity services can handle token minting and management.
Clients complete the OAuth flow while servers validate tokens
Kasper explains that developers can reference metadata pointing to an existing authorization server and continue using standard OAuth 2.0 libraries. The client handles the end-to-end token flow, including acquiring and validating the authorization result before sending it to the server. The server still has to validate the token and publish the required metadata. This reduces the amount of security code an MCP developer has to write.
When a client requests data without user context, the MCP server returns HTTP 401 and includes a pointer to a protected resource metadata document in the WWW-Authenticate header. The client reads that document to find the authorization server, supported methods, and scopes. It then performs the standard OAuth discovery and authorization flow, obtains a token, and retries the request. The metadata document tells the client how to start the process without server-specific token management.
The C# example uses an ASP.NET Core application and the official MCP C# SDK. Delimarsky configures authentication with the MCP OAuth scheme, adds token validation, supplies protected resource metadata, and enables authentication and authorization. The metadata identifies the authorization server, scopes, and supported bearer authentication method. On the client side, the example specifies a generic OAuth provider, client ID, and scopes. The client discovers the metadata, gets a token from Microsoft Entra ID, sends it to the server, and invokes a simple weather tool.
Kasper recommends placing Azure API Management between clients and a remote MCP server. Her sample uses an Azure Developer CLI app to deploy the resources, including API Management, an app service plan, and logging resources. The gateway handles the connection to Microsoft Entra ID, including login and consent, while the remote MCP server exposes three tools. She connects the endpoint to MCP Inspector, approves the consent screen, and lists the available tools.
Kasper shows an Azure API Management feature that transforms existing REST API endpoints into remote MCP servers. The platform produces tools from the configured REST operations, while OAuth can protect the endpoint. She adds the generated endpoint to VS Code, where GitHub Copilot detects the MCP server and displays the three resulting tools. This lets an existing API become available to MCP clients without writing a separate tool implementation for every operation.
"Remote MCP servers are super important because anybody can access them, especially if the servers are open to the broad internet, not behind a VPN."00:53
Who should watch
You are building a remote MCP server that calls APIs with user-specific permissions and need to understand which side handles tokens.
Your MCP server works locally and you are preparing to deploy it on the public internet or behind an API gateway.
You have existing REST APIs and want to expose their operations to MCP clients such as MCP Inspector or VS Code.
