MCP Authentication and Authorization: Current State and Future
As of July 2025, the Model Context Protocol (MCP) has evolved through three major versions (2024-11-05, 2025-03-26, and 2025-06-18). Today, MCP has become an integral part of our daily development workflow, with developers launching MCP servers via npx commands, uv commands, or Docker containers from MCP clients like Cursor, Claude Code, and VS Code, while also connecting to remote MCP servers.
Examining the MCP Servers - Cursor library demonstrates significant ecosystem growth, with numerous services investing in their own MCP server implementations.
Examples include: Notion, Figma, Linear, and GitHub.
Particularly, the Atlassian Remote MCP Server beta is one of the most advanced MCP servers officially provided by a service.
When I launch Cursor, a browser automatically opens, directing me to log in to my Atlassian account. After confirming the scope of access permissions on the authorization screen, AI agents can then access my Confluence and Jira resources through the MCP server.
This OAuth flow provides exceptional convenience for end users by eliminating the need to manage API keys, expiration dates, or secure storage methods. The MCP specification recommends short-lived access token issuance, and while specific token lifetimes and refresh behaviors depend on Authorization Server (AS) implementation policies (such as Atlassian's), browsers automatically guide users through re-authentication when tokens expire.
MCP's OAuth implementation succeeds because it aligns well with existing OAuth ecosystems through OAuth 2.1 compliance, Authorization Server separation, and PKCE principles. However, the current OAuth specification also presents significant challenges that hinder enterprise adoption. This article examines these limitations while exploring proposed MCP specification changes and Okta's solution approach based on publicly available materials, providing insights for enterprise MCP adoption roadmaps.
I am not an OAuth expert, so this article may contain inaccuracies. Please refer to the materials listed in References for detailed information.
Limitations of Dynamic Client Registration
MCP's OAuth specification is known to be based on OAuth 2.1.
This means there are four main actors:
- Client: MCP clients such as Cursor, Claude Code, MCP Inspector, etc.
- Resource Server: MCP servers and servers that hold protected resources (Confluence, Jira, etc.) that MCP servers access
- Authorization Server: The authorization server in OAuth that issues access tokens for services
- Browser: The browser operated by the user
The flow involves the client being registered with the authorization server, obtaining access tokens from the authorization server via the browser, and accessing the resource server.
In standard OAuth 2.1 implementations, clients must be pre-registered with authorization servers. Confidential Clients, for instance, require Client IDs (and Client Secrets) to obtain access tokens.
However, MCP enables OAuth flows with minimal configuration. While Client IDs (and Client Secrets) should theoretically be pre-configured and registered with authorization servers, they can be omitted in configurations like this:
"mcp-atlassian": {
"url": "https://mcp.atlassian.com/v1/sse"
}
This simplicity is possible because MCP doesn't require pre-registered clients. Instead, MCP recommends Dynamic Client Registration, enabling clients to register with authorization servers via the /register
endpoint and obtain access tokens without prior registration.
This is a very convenient feature designed to make MCP easy to use. However, Dynamic Client Registration has several limitations:
- Security concerns: Dynamic Client Registration automatically generates Client IDs (and Client Secrets) when clients register with authorization servers, but there's a possibility of malicious client registration. Particularly in enterprise environments, security policies typically allow only pre-registered clients.
- Need for Dynamic Client Registration support: To use Dynamic Client Registration, authorization servers must support this feature, but not all authorization servers do. Especially in enterprise environments, existing authorization servers may not support Dynamic Client Registration.
While Okta supports Dynamic Client Registration, it requires administrator-level authentication (such as API tokens), making unauthenticated Dynamic Client Registration impossible. Google's public documentation reveals no general-purpose Dynamic Client Registration API, typically requiring static client registration through their console. Consequently, neither Okta nor Google can serve directly as OAuth authorization servers in MCP implementations.
So how does Atlassian's Remote MCP Server support Dynamic Client Registration without additional credentials? They provide their own Authorization Server that implements Dynamic Client Registration.
Atlassian publishes OAuth 2.1-based AS metadata and directs users to OAuth flows via browsers when starting Remote MCP Server connections (https://mcp.atlassian.com/v1/sse). Here, Atlassian provides an MCP-specific authorization server, which then utilizes the authorization server that constitutes Atlassian's original account ecosystem.
This approach of combining two authorization servers is currently widely adopted. If you want to try it yourself, you can learn the details from remote-mcp-github-oauth - Cloudflare AI. Using the workers-oauth-provider library provided by Cloudflare for configuring OAuth providers, you can configure and provide your own Dynamic Client Registration.
However, this approach introduces significant implementation complexity and requires MCP server operators to assume authorization server responsibilities. OAuth implementations are inherently risky without advanced security expertise due to potential vulnerabilities. While proven libraries like Cloudflare Workers' workers-oauth-provider can mitigate risks by supporting .well-known/DCR/PKCE from the ground up, the approach remains costly and risky for typical enterprise scenarios where organizations simply want to configure appropriate MCP server access restrictions for internal employees.
Unclear Authorization Specifications for Backend Services
What are the best practices for MCP servers within general companies, especially when these MCP servers access internal resources (Backend Services), for internal employees?
These internal resources encompass cloud databases from Amazon Web Services, Google Cloud, and Azure; metrics and logs from observability platforms like New Relic and DataDog; and knowledge bases including Google Workspace, Notion, and Confluence. While integrating these systems with MCP servers for automation represents a critical business need, securely granting MCP servers appropriate access permissions remains challenging.
A commonly used approach is to grant access permissions through Machine Users or Service Accounts with unified permissions. This is very easy to set up - focusing on just one permission and exposing it under certain access restrictions. However, this can cause the Confused deputy problem. Consider an organization where the knowledge base has documents that only specific departments (HR, Finance, etc., highly confidential departments) can view, but an MCP server is configured with unified Machine User permissions to read all knowledge base documents, and this MCP server is set up to be accessible by all employees. An employee from another department could access important internal documents through the internal MCP server that should have been prohibited from viewing based on their originally granted account permissions. While this isn't a problem limited to MCP or AI, it represents a serious configuration error that breaks existing access boundaries set by department or individual.
The best practice approach in this case is to obtain access tokens for each user through OAuth flows that are guaranteed to be a subset of the user's existing access permissions, and have MCP servers access Backend Services resources using only those tokens. This preserves existing access boundaries and prevents the Confused deputy problem.
MCP addresses the foundational challenge of "which Authorization Server to obtain tokens from and how" through RFC 9728 (Protected Resource Metadata) and RFC 8707 (Resource Indicators). RFC 9728 enables dynamic discovery of correct Authorization Servers and resource identifiers from protected resource metadata, while RFC 8707 provides proper scope and resource indication for token acquisition. These standards align with MCP's Authorization Server separation design and establish the foundation for multi-Authorization Server authorization flows. Nevertheless, best practices for MCP servers that aggregate resources from multiple backend services while maintaining proper authorization mechanisms remain undefined, creating barriers for enterprise deployment of centrally managed MCP server infrastructure.
One idea for circumventing these limitations is to provide only the
auth
Tool from MCP servers when authorization is not yet complete, provide URLs to start OAuth flows from this Tool to MCP clients, and after obtaining access tokens, send List Changed Notifications to expose the originally available Tools to MCP clients.However, this is merely an alternative using existing MCP specifications, and it remains doubtful whether this would actually become a best practice.
What is the Addition of MCP's Enterprise-Managed Authorization Profile Specification?
Given the limited ecosystem support for Dynamic Client Registration and the current MCP specification's inadequate handling of proper backend service access permissions via OAuth, the existing MCP specification falls short of enterprise requirements.
However, there is currently a PR in the MCP specification repository that can be expected to improve these issues: Enterprise-Managed Authorization Profile for MCP #646 (preview).
This proposal introduces a new authorization flow based on the Identity Assertion Authorization Grant, currently published as an Internet-Draft.
Here, there are five actors:
- Browser: The browser operated by the user
- MCP Client: MCP clients such as Cursor, Claude Code, MCP Inspector, etc.
- Identity Provider: User management providers in Enterprise environments such as Okta and Google
- MCP Authorization Server: Authorization servers provided by Atlassian, Notion, DataDog, etc.
- MCP Resource Server: MCP servers and servers that hold protected resources (Confluence, Jira, etc.) that MCP servers access
The authorization flow works as follows:
- When a user enables the use of an MCP server in an MCP client like Cursor, a browser automatically opens, displaying the login screen of the IdP (Okta, Google, etc.), and the user logs in using their employee ID, etc.
- After successful login to the IdP, an authorization code is provided to the MCP client via the browser, and the MCP client uses this authorization code to obtain an ID token from the IdP for the Identity Assertion mechanism. This ID Token is stored in the MCP client.
- The MCP client includes the ID Token and the identifier of the MCP server it's trying to access, and obtains an Assertion Token (Identity Assertion JWT) from the IdP using the Identity Assertion JWT Authorization Grant (ID-JAG) mechanism.
- The MCP client sends the Assertion Token using the ID-JAG mechanism and obtains an access token.
- The MCP client uses this access token to access the MCP Resource Server.
Once the MCP client obtains the ID Token, subsequent processes occur without browser intervention. From the user's perspective, completing IdP authentication automatically provides access tokens for all services permitted by the IdP administrator. This eliminates the need to issue and configure access tokens for individual services or execute separate OAuth flows—MCP server functionality becomes accessible through a single IdP login action.
What is Okta's Cross App Access?
What role do IdPs like Okta play in MCP's OAuth specification based on this Identity Assertion Authorization Grant? This can be inferred from several pieces of public information about Cross App Access provided by Okta.
A key characteristic of this architecture is the IdP's role as a centralized hub for access token issuance across all services.
Enterprise IdP administrators typically manage both users and services within platforms like Okta and Google. Most enterprise environments already feature extensive service integrations providing automatic provisioning via SCIM and IdP-mediated authentication via SAML. This specification extends IdP capabilities to include access token management delegation. IdP administrators gain control over which OAuth clients can automatically obtain access tokens for specific services, while gaining visibility into access token issuance through ID-JAG (Identity Assertion JWT Authorization Grant) status monitoring.
By having the IdP intervene in access token issuance processes that were previously performed independently within each service, Enterprise environment administrators can gain more centralized management and visibility, and can replace long-term valid access tokens and API keys that have been overlooked in each service.
Current Concerns
A primary concern involves service adoption rates. The capability to "impersonate users and issue access tokens with specified scopes without user approval" exists in implementations like Google Workspace's Domain Wide Delegation, but most services likely remain unsupported. Okta announced Cross App Access functionality for selected customers in Q3 2025 (announced June 23, 2025), highlighting that ecosystem alignment between ISVs and enterprises will be crucial. Continued monitoring of individual service adoption remains essential.
Also, regarding MCP usage, Enterprise-Managed Authorization Profile for MCP #646 points out that Dynamic Client Registration is not used for OAuth client registration, and MCP clients need to be registered with both the IdP and MCP Authorization Server, meaning the equivalent of Client ID (and Client Secret) in OAuth needs to be distributed to users in advance.
The MCP client will likely need to be pre-registered with the enterprise IdP for single sign-on.
It is also assumed that the MCP client will be pre-registered with the MCP server's authorization server.
While enterprise environments typically maintain user environment control through Mobile Device Management (MDM) and similar systems, the specification doesn't detail how to implement pre-registration across diverse MCP clients like Cursor, Claude Code, and MCP Inspector. This requires coordinated support implementation across IdPs, MCP Authorization Servers, and individual MCP clients.
Conclusion
Although MCP's current authentication and authorization specifications present significant challenges for enterprise deployment, ongoing improvement efforts point toward a future where enterprise access permission management becomes more centrally managed through IdPs.
While the prospects of centralized management, improved visibility, and enhanced user experience are promising, significant implementation barriers remain. Continued monitoring of these developments will be essential for successful enterprise MCP adoption.
References
- Dynamic Client Registration - MCP
- Enterprise-Ready MCP - Aaron Parecki
- Enterprise-Managed Authorization Profile for MCP #646
- Enterprise-Managed Authorization - GitHub
- Enterprise-Managed Authorization - MCP Staging
- Identity Assertion Authorization Grant - IETF Datatracker
- oktadev/id-assertion-authz-node-example
- Cross-App Access - Okta Platform
- Okta introduces Cross App Access to help secure AI agents in the enterprise