In the rapidly evolving landscape of AI technology, a significant development recently emerged that might have flown under your radar. On April 26, 2025, a new authorization specification for Model Context Protocol (MCP) was published, developed through collaboration between Anthropic and various industry partners.
What is MCP and Why Does This Matter?
The Model Context Protocol serves as a standardized way for AI systems to interact with external resources and services. As AI models become more powerful and deeply integrated into our digital infrastructure, establishing secure authorization methods becomes critical. This new specification addresses this need by simplifying how AI systems can securely access resources.
Key Improvements in the New Specification
The most significant change in this specification is the clear separation between two crucial components:
- Resource Provider (RP) – The server that hosts the AI model or service
- Authorization Server (AS) – The system that handles authentication and permissions
Previously, developers were expected to implement both components together, which created unnecessary complexity. Many developers would need to build their own Authorization Servers from scratch – a task that’s notoriously difficult to get right from a security perspective.
The new specification acknowledges the existence of established third-party Authorization Servers (like Entra ID, Okta, Auth0, and others) that can be integrated more easily with MCP servers.
How It Works: The Discovery Process
Every MCP server will now host a Protected Resource Metadata (PRM) document in a standardized location (/.well-known/resource-metadata). This document, based on RFC 9732, contains essential information about:
{
"resource": "https://resource.example.com",
"authorization_servers": [
"https://as1.example.com",
"https://as2.example.net"
],
"bearer_methods_supported": [
"header",
"body"
],
"scopes_supported": [
"profile",
"email",
"phone"
],
"resource_documentation": "https://resource.example.com/resource_documentation.html"
}When a client first communicates with an MCP server, the discovery process follows a clean, logical flow:
- The client receives a standard HTTP 401 Unauthorized response
- This response includes a WWW-Authenticate header with a
resource_metadatafield - The client follows this link to retrieve the PRM document
- From the PRM, the client identifies the appropriate Authorization Server
- The client initiates the authorization process using industry-standard OAuth 2.0 with PKCE (Proof Key for Code Exchange)
The Authorization Flow in Detail
The MCP specification implements OAuth 2.0 authorization code flow with PKCE, which provides enhanced security against code interception attacks. This flow works as follows:
- The client generates a code verifier (a random string) and creates a code challenge by applying SHA-256 to the verifier
- The client sends an authorization request to the Authorization Server with the code challenge
- After user authentication, the Authorization Server returns an authorization code
- The client exchanges this code for an access token, including the original code verifier
- The client can then use this token to access protected resources on the MCP server
This approach is particularly important for public clients (like browser-based applications) where traditional client authentication methods might not be applicable.
What This Means for Developers
For developers implementing MCP servers, this specification drastically reduces the burden of building secure authorization systems. Instead of creating custom token services, they can leverage existing Authorization Servers that handle the complex aspects of token management, user authentication, and security best practices.
There are still some considerations – particularly around Dynamic Client Registration (DCR) support – but overall, this represents a major simplification of the authorization landscape for MCP implementations.
The Power of Collaboration
Perhaps the most impressive aspect of this specification is how it demonstrates the power of collaborative development in the AI ecosystem. With contributions from experts at companies like Microsoft, Okta/Auth0, Arcade.dev, Hellō, Stytch, Descope, and many others, the specification represents a broad consensus on best practices for AI system authorization.
As noted in the original announcement:
“This has been a massive collaboration with folks at Microsoft, Okta/Auth0, Arcade.dev, Hellō, Stytch, Descope, and many, MANY, more.”
This type of cross-industry collaboration is exactly what we need to ensure that AI systems develop with appropriate security guardrails in place.
What’s Next for MCP Authorization
The specification continues to evolve, with ongoing work focused on additional security best practices. These incremental changes will help ensure that MCP server developers implement authorization in ways that protect both their systems and their users’ data.
Meanwhile, implementation work has already begun, with SDKs being updated to support the new specification. The MCP C# SDK is among the first to receive these updates, with other languages and platforms likely to follow soon.
Conclusion
The new MCP Authorization Specification is a significant step forward in making AI systems both more powerful and more secure. By separating resource providers from authorization servers and leveraging established security protocols, it creates a more flexible, interoperable, and secure foundation for AI system development.
For developers looking to implement these standards, the complete specification provides detailed implementation guidance and should be your first stop in understanding this important development in AI security.
References
[1] MCP Authorization Specification (Draft): https://modelcontextprotocol.io/specification/draft/basic/authorization
[2] Protected Resource Metadata (RFC 9732): https://www.rfc-editor.org/rfc/rfc9732.html
[3] OAuth 2.0 with PKCE (RFC 7636): https://www.rfc-editor.org/rfc/rfc7636
