In MCP, every request comes from a nonhuman identity: an agent, server or tool. These identities don’t act under direct human oversight. They generate requests dynamically, chain operations and carry data across trust boundaries. Without rigorous authentication and authorization, a compromised agent can impersonate legitimate clients, replay tokens or escalate privileges across your entire system.
The MCP Security Best Practices specification doesn’t offer a menu of optional patterns. It mandates specific authentication requirements and five authorization patterns that must be implemented without exception. Understanding these requirements is essential for building secure MCP systems.
The Core MCP Security Challenge: Confused Deputy Attacks
Before examining authentication patterns, you need to understand the threat they’re designed to prevent. The confused deputy problem is the most significant MCP-specific security challenge.
In a confused deputy attack, an attacker exploits trust relationships by tricking a legitimate client into performing unauthorized actions on their behalf. Here’s how it works: A user authorizes Application A to access enterprise data through an MCP server. Without proper controls, a malicious Application B could use the same user credentials to access that data, effectively impersonating Application A.
The MCP server becomes the “confused deputy” because it has legitimate authorization but applies it incorrectly. The server assumes that user authentication implies authorization for all clients. That assumption is the vulnerability.
This threat drives every authentication and authorization requirement in the MCP specification. The goal isn’t just verifying identity. It’s ensuring that authorization is granted explicitly to specific clients for specific operations, validated on every request and enforced server-side without exception.
Authentication Requirements for MCP
The MCP specification establishes clear authentication requirements. Some patterns are mandatory, others are prohibited, and the specification leaves little room for interpretation.
OAuth 2.1 Is the Foundation
The MCP specification explicitly references OAuth 2.0 Security Best Practices (RFC 9700), indicating that implementations must follow OAuth 2.1 guidance. This means Authorization Code Flow with PKCE for client applications and Client Credentials Flow for server-to-server authentication.
OAuth 2.1 consolidates security best practices and addresses vulnerabilities in earlier OAuth versions. PKCE (Proof Key for Code Exchange) prevents authorization code interception attacks by binding the authorization request to the token request through cryptographic verification.
Token-based authentication offers broad support and straightforward integration with existing identity infrastructure. However, tokens create risks in agentic environments. An agent might inadvertently include its token in data sent to a tool. Downstream components may echo or leak tokens to third parties. If tokens are long-lived or broadly scoped, an attacker who captures one gains wide access.
The specification addresses these risks through mandatory token controls: short life spans (15-60 minutes recommended), refresh token rotation where each use invalidates the previous token, and strict audience validation.
Token Audience Validation Is Mandatory
Every token validation must verify that the token’s aud (audience) claim matches the MCP server’s identifier. This prevents attackers from reusing valid tokens obtained for one service against a different service.
Even if a token is properly signed, unexpired and issued by a trusted authorization server, it must be rejected if the audience claim specifies a different recipient. Validate audience on every request, not just during initial authentication.
Session-Based Authentication Is Prohibited
The MCP specification establishes an absolute prohibition: MCP servers must not use sessions for authentication. This eliminates the entire class of session hijacking vulnerabilities by removing the session management layer that attackers would target.
All authentication must use tokens validated on each request, never through server-maintained session state. If your current architecture relies on session cookies for workload authentication, MCP compliance requires architectural changes.
Token Passthrough Is Forbidden
The specification explicitly forbids token passthrough, where an MCP server forwards authentication tokens through intermediaries rather than validating them directly. If an attacker compromises any intermediary (logging system, proxy server, middleware component), they can capture valid tokens and impersonate legitimate users.
Every MCP server must validate tokens directly against the authorization server. If the server needs to access downstream services on behalf of the user, it must obtain its own tokens through delegation mechanisms like OAuth token exchange, not pass through the user’s original token.
Certificate-Based Authentication for High-Security Environments
For environments requiring stronger cryptographic assurance, the specification supports mutual TLS (mTLS) as an enterprise-grade authentication mechanism alongside OAuth. Certificate-based authentication binds identity to cryptographic keys, making replay attacks significantly harder.
Standards like SPIFFE/SPIRE provide workload identity frameworks that issue and rotate certificates automatically. This addresses the operational complexity of certificate management in dynamic environments where agents spin up and down frequently.
The trade-off is operational overhead. Distributing, rotating and revoking certificates requires orchestration infrastructure. Bootstrapping identities in ephemeral workloads demands automation. But for core agent-server trust relationships in high-security MCP deployments, certificate-based authentication provides the strongest foundation.
Federated Identity for Cross-Cloud Scenarios
Workload identity federation enables agents to authenticate using existing cloud identity infrastructure: AWS IAM roles, GCP Workload Identity Federation, Azure Managed Identities or OIDC federation bridging external identity systems.
Federation avoids static secrets and manual credential management while providing audit trails through existing IAM tooling. However, trust relationships between identity domains must be configured precisely. Misconfigured federation boundaries can allow agents in one project or cloud to assume privileges intended for another.
Cross-cloud federation adds complexity. Token exchange, identity mapping and trust propagation introduce latency and potential failure points. But for MCP deployments spanning multiple environments, federation provides the scalability that static credentials cannot.
The Five Mandatory Authorization Patterns
The MCP specification defines five authorization patterns that must be implemented without exception. These aren’t options to evaluate and choose between. They’re requirements.
1. Per-Client Consent
A user’s general authentication does not imply authorization for any specific client to act on their behalf. The MCP server must maintain a consent registry mapping user identifiers to approved client identifiers with granted scopes.
When the server receives a request, it must validate that the user has granted consent specifically to the requesting client application. This validation must occur server-side. Client-side validation is never sufficient because malicious clients can bypass or modify client-side checks.
The consent interface should explicitly identify which client application is requesting access, what resources or operations the application will access, what data it will read or modify and the duration of authorization. Users need enough information to make informed decisions.
2. Token Audience Validation
Verify the “aud” claim in JWT tokens matches your server’s identifier on every request. Reject tokens intended for different services even if they’re properly signed and unexpired. This is part of confused deputy problem mitigation: even valid tokens must be rejected if they weren’t issued for your specific server.
3. Rejection of Token Passthrough
Never forward tokens through your MCP server to backend services. Validate tokens directly with the authorization server. Use token exchange mechanisms when you need to access downstream services. This requirement exists because token passthrough creates theft opportunities at every intermediary point.
4. Exact Redirect URI Matching
OAuth redirect URI validation must use exact string matching. Maintain a registry of exact redirect URIs for each client. A registered URI of https://app.example.com/oauth/callback must reject variations with additional query parameters, path segments, different subdomains or protocol changes.
Partial matching or wildcards create open redirect vulnerabilities where attackers can redirect users to malicious sites that capture authorization codes.
5. OAuth State Parameter Validation
Generate cryptographically random state values with minimum 128 bits of entropy. Store the state securely before initiating the authorization flow. When processing the callback, validate that the returned state parameter matches the stored value.
Missing or mismatched state parameters indicate potential CSRF attacks and must be rejected. Never skip state validation, and never use predictable state values.
Transport Security Requirements
HTTPS is mandatory for all MCP authorization endpoints with no exceptions. The specification is explicit: HTTP connections must be rejected at the network level, not redirected.
Enforce TLS 1.2 as the minimum version, with TLS 1.3 preferred. Use strong cipher suites and disable weak ciphers (RC4, DES, 3DES). Implement HTTP Strict Transport Security headers. Certificates must be issued by trusted Certificate Authorities and must not be expired or self-signed in production.
For local MCP servers, the specification recommends stdio transport over network-based transport. Stdio communicates through standard input/output streams and eliminates network exposure entirely.
Beyond Patterns: Context-Aware Policy Enforcement
The five mandatory patterns establish the foundation, but production MCP deployments benefit from additional policy-based access control that considers runtime context.
Conditional access policies can evaluate security posture before granting access. An agent on a compromised host with outdated patches shouldn’t receive the same authorization as one in a verified secure environment. Integrate with endpoint detection tools to verify system compliance. Implement geolocation checks and time-based restrictions for scheduled operations.
Attribute-based policies can enforce constraints beyond static roles: agent type, environment tags, request timing, tool sensitivity and compliance status. A billing agent might access payment tools only when the request includes a valid account identifier, the time falls within business hours, and the source environment passes compliance checks.
The trade-off is complexity. Policy management grows quickly, and unexpected interactions between rules can create gaps. Auditing and explaining policy decisions at scale requires a robust observability infrastructure.
Implementing These Patterns at Scale
Implementing consistent authentication and authorization across an agentic architecture is operationally challenging. Nonhuman identities now outnumber human users in most organizations. Each identity needs cryptographic verification, policy evaluation and audit logging.
Aembit addresses these challenges through workload IAM purpose-built for MCP and similar architectures:
- Per-client consent enforcement with centralized policy management ensures that authorization is granted and validated per client application, directly addressing the confused deputy problem.
- Secretless access eliminates long-lived credentials by issuing just-in-time tokens that expire after use. This reduces token leak risks and removes static secrets that create persistent attack vectors.
- Cross-environment consistency federates identities across on-premises, AWS, Azure, GCP and SaaS environments, reducing misconfiguration risks in multicloud MCP deployments.
- Conditional access controls enforce policies based on security posture, geolocation, time-based restrictions and compliance status, adapting authorization to real-time conditions.
- Comprehensive audit trails log all authentication events, policy decisions and authorization outcomes for observability and compliance.
The goal is to make authentication invisible to developers while giving security teams the control and visibility they need. MCP’s specific requirements demand purpose-built tooling that understands the five mandatory patterns and enforces them consistently across every agent, server and tool interaction.
