MCP Authentication Explained for Developers: None, Headers, OAuth, Per-User OAuth, and Token Exchange

TL;DR

• MCP authentication governs how AI hosts and intermediate gateways verify identity before allowing autonomous agents to execute remote tools or access protected resources.
• Transport types determine credential handling: local STDIO transports rely on parent process environment variables, while remote HTTP and Server-Sent Events (SSE) transports require structured HTTP authorization.
• Server-level credentials (Headers and Admin OAuth) provide a single shared identity for all callers, whereas Per-User OAuth and Token Exchange preserve individual authorization boundaries.
• RFC 8693 Token Exchange enables on-behalf-of delegation, converting enterprise identity tokens into short-lived, downstream tool tokens without storing static secrets.
• Centralized gateways such as Bifrost streamline token lifecycle management, virtual key rate limiting, and tool-level access control across heterogeneous MCP servers.

The Model Context Protocol (MCP) defines an open standard for connecting AI models to external tools, databases, and APIs, yet connecting an autonomous agent to enterprise infrastructure introduces severe access control challenges. Bifrost, an open-source AI gateway written in Go by Maxim AI, provides a centralized control plane to route, monitor, and enforce access controls across these tools. Securing these interactions requires understanding the five distinct authentication patterns available in MCP architectures: None, static Headers, server-level OAuth, Per-User OAuth, and RFC 8693 Token Exchange. Choosing the wrong authentication model risks exposing shared service credentials, breaking enterprise auditability, or granting broad ambient authority to automated workflows.

The Core Challenge: Securing Tools in Agentic Architectures

MCP authentication governs the verification and authorization of requests passing between three primary components: the MCP host (such as an IDE, desktop assistant, or agent framework), the MCP client (which manages protocol communication), and the MCP server (the service exposing executable tools and contextual resources).

+-------------------------------------------------------------+
|                     AI Agent Host / Client                  |
|          (Cursor, Claude Desktop, Custom Agent Runtime)     |
+-------------------------------------------------------------+
                              |
                     Transport Connection
                     (STDIO vs HTTP / SSE)
                              |
                              v
+-------------------------------------------------------------+
|                   AI Gateway / Control Plane                |
|       (Bifrost: Virtual Keys, Governance, Credential Store)  |
+-------------------------------------------------------------+
                              |
                     Authenticated Request
        (None | Headers | OAuth | Per-User OAuth | RFC 8693)
                              |
                              v
+-------------------------------------------------------------+
|                         MCP Server                          |
|         (File System, GitHub, Jira, Internal Database)      |
+-------------------------------------------------------------+

In standard web applications, authentication typically terminates at an edge reverse proxy, with requests scoped to a single authenticated human session. AI agents disrupt this paradigm because they act as autonomous intermediaries. An agent might accept a prompt from an engineer, analyze a bug, inspect private repositories via GitHub, query a staging database, and post an update to a ticketing system.

If every tool call uses a single hardcoded API key, two fundamental security failures occur:

1. Broken Principle of Least Privilege: The agent possesses full administrative privileges across all connected systems, regardless of who initiated the prompt.
2. Loss of Audit Attribution: In system logs, every operation appears under a generic service account rather than the individual engineer directing the agent.

Securing tool invocation requires aligning the transport layer with the appropriate cryptographic identity. The official Model Context Protocol Authorization specification establishes guidelines specifically for remote transports, distinguishing between local process execution and network-based invocation.

Transport Architecture: STDIO vs. HTTP and SSE

MCP implementations operate over two primary transport categories, each with distinct authentication constraints:

• Standard Input/Output (STDIO): The MCP host spawns the server as a local child process and communicates directly over standard input and standard output streams. STDIO connections inherit the environment variables of the spawning process. Because there is no network socket, these connections do not use HTTP headers or OAuth handshakes. Security relies on local machine permissions and filesystem access controls.
• HTTP and Server-Sent Events (SSE): The MCP server operates as an independent web service reachable over HTTP POST endpoints or persistent SSE streams. Network boundaries demand explicit transport-level authentication, standardized via HTTP request headers, bearer tokens, or dynamic OAuth handshakes.

Developers deploying production agents primarily focus on HTTP and SSE architectures, where multiple users, shared servers, and distributed environments intersect.

The Spectrum of MCP Authentication: An Architecture Comparison

Selecting an authentication pattern involves trading implementation complexity against security granularity. While static tokens are simple to set up, they cannot enforce user-level isolation in multi-tenant environments.

Auth Type	Who Authenticates	Credential Shape	Transport Compatibility	Identity Boundary	Primary Use Case
None	Anonymous	None	STDIO, HTTP, SSE	Public / Unrestricted	Local read-only tools, public docs search, weather APIs.
Headers	Administrator (once)	Static HTTP headers / API keys	HTTP, SSE	Server-level (Shared)	Shared internal microservices, single-tenant utilities.
OAuth 2.0 (Admin)	Administrator (once)	Access and refresh tokens	HTTP, SSE	Server-level (Shared)	Shared third-party services (corporate Slack bot, status monitoring).
Per-User OAuth	End user (lazily)	User-scoped access token	HTTP, SSE	User-level (Personal)	Multi-tenant SaaS tools (GitHub, Notion, Linear, personal email).
Token Exchange (RFC 8693)	Caller / Gateway (per call)	Ephemeral exchanged token	HTTP, SSE	User-level (Delegated)	Enterprise microservices, internal data warehouses, zero-trust platforms.

When running Bifrost as an MCP gateway, engineering teams can centralize these varied upstream patterns into a single interface. Rather than managing different authentication libraries inside each client application, the gateway negotiates upstream credentials based on predefined policies.

1. Anonymous Access (None): When Unauthenticated MCP Makes Sense

The none authentication pattern passes zero authentication metadata to the target server. While running unauthenticated endpoints across enterprise networks is generally an anti-pattern, anonymous access serves specific, constrained purposes in AI workflows:

1. Air-gapped and Local STDIO Tools: Standalone utilities, such as calculating hashes, executing local mathematical formulas, or querying bundled static assets, operate in isolated execution environments where network credentials are unnecessary.
2. Public Data Retrieval: Tools querying public search endpoints, open documentation repositories, or unauthenticated health check endpoints require no caller verification.

{
  "mcpServers": {
    "public-docs": {
      "url": "https://mcp.internal.example/docs",
      "transport": "http",
      "auth": {
        "type": "none"
      }
    }
  }
}

Even when an upstream tool uses none, exposing it directly to client applications creates vulnerability to denial-of-service or query flooding. In production, unauthenticated upstream tools should sit behind a gateway where rate limits and budget caps can still be applied per consumer.

2. Static and Per-User Headers: API Keys and Bearer Tokens

The headers authentication pattern attaches fixed HTTP headers (such as Authorization: Bearer <token> or X-API-Key: <key>) to every outgoing request. In server-level configurations, an administrator provisions this secret once during server registration, and all subsequent agent requests inherit the same credential.

POST /mcp/tools/call HTTP/1.1
Host: mcp.internal.example
Content-Type: application/json
Authorization: Bearer sk-service-prod-98742847291
X-Org-Scope: engineering

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "query_inventory",
    "arguments": { "sku": "A100-80GB" }
  },
  "id": 1
}

Static Admin Headers vs. Per-User Headers

Static headers function reliably for internal infrastructure where tool operations are naturally scoped to a shared service account. For example, an MCP server that queries cloud infrastructure metrics or fetches platform deployment logs can safely authenticate via an administrator-configured token.

However, static shared headers fail when individual users execute operations through the same agent interface. If an engineer asks an agent to update a customer database, a shared header obscures which engineer requested the change.

To solve this, advanced gateways introduce Per-User Headers (per_user_headers). In this mode, the platform tracks end-user credentials against unique identities, such as a virtual key or an authenticated session token. When a specific user invokes an agent action, the proxy dynamically injects that specific user's custom API key or personal bearer token into the upstream request.

3. Server-Level OAuth 2.0: Shared Enterprise Credentials with Auto-Refresh

Static tokens present major operational liabilities: they do not expire automatically, rotation requires coordinated configuration restarts, and revocation disrupts all active operations. Server-level OAuth 2.0 (oauth) modernizes this workflow by introducing dynamic authorization code handshakes, scoped permissions, and automated token refresh.

In this model, an administrator executes an OAuth flow once when connecting the MCP server. The gateway or client acts as an OAuth 2.1 client, requests authorization against the remote provider, acquires an access token alongside a refresh token, and stores them securely in an encrypted vault.

Protocol Discovery and the Metadata Standards

The official MCP specification adopts modern IETF standards to eliminate manual OAuth configuration. When an MCP client attempts to connect to an OAuth-protected MCP server, the handshake follows a structured discovery sequence:

1. Initial Challenge: The client attempts an unauthenticated request. The MCP server returns an HTTP 401 Unauthorized response with a WWW-Authenticate header pointing to its protected resource metadata.
2. Protected Resource Metadata (RFC 9728): The client fetches /.well-known/oauth-protected-resource to discover the canonical resource identifier and the authorized Authorization Server (AS) endpoints.
3. Authorization Server Metadata (RFC 8414): The client queries /.well-known/oauth-authorization-server to resolve the authorization endpoint, token endpoint, and supported scopes.
4. Dynamic Client Registration (RFC 7591): If the client lacks a hardcoded client_id, it registers itself dynamically with the authorization server, establishing unique client credentials on the fly.
5. PKCE Enforcement: In alignment with OAuth 2.1 draft guidelines, the client initiates an Authorization Code flow using Proof Key for Code Exchange (PKCE) with code challenges, preventing authorization code interception attacks.

+-----------+            +-------------+            +---------------+
| MCP Host  |            |  AS / IdP   |            |  MCP Server   |
+-----------+            +-------------+            +---------------+
      |                         |                           |
      | 1. Unauthenticated GET  |                           |
      |---------------------------------------------------->|
      | 2. HTTP 401 + WWW-Authenticate (RFC 9728 link)     |
      |<----------------------------------------------------|
      |                                                     |
      | 3. Query Protected Resource Metadata (RFC 9728)     |
      |---------------------------------------------------->|
      | 4. Return authorization_servers endpoints           |
      |<----------------------------------------------------|
      |                                                     |
      | 5. Resolve AS Metadata (RFC 8414)                   |
      |------------------------>|                           |
      | 6. Return token/auth URLs                           |
      |<------------------------|                           |
      |                                                     |
      | 7. Auth Code Flow + PKCE (OAuth 2.1)                |
      |<=======================>|                           |
      | 8. Issue access_token & refresh_token               |
      |<------------------------|                           |
      |                                                     |
      | 9. Authenticated Call (Bearer access_token)         |
      |---------------------------------------------------->|
      | 10. Execute Tool & Stream Result                    |
      |<----------------------------------------------------|

When managing this lifecycle through Bifrost, the gateway monitors token validity windows and initiates automatic refresh requests against the authorization server before the token expires. The client application remains agnostic of the underlying refresh cycles.

4. Per-User OAuth: Personal Data Boundaries and Delegated User Consent

Server-level OAuth works effectively when an entire organization shares access to an external tool, such as an incident alert broadcaster. But when tools interact with user-specific SaaS platforms—such as Notion, GitHub, Linear, or Jira—shared authorization breaks down.

Under a shared model, if an engineer requests an agent to "summarize pull requests assigned to me," the server only sees the service account's pull requests. Worse, if the shared credential has administrative access, an unprivileged user could prompt the agent to delete production branches or read confidential executive boards.

Per-User OAuth (per_user_oauth) solves this by binding upstream tokens directly to individual user identities.

The Lazy Authentication Handshake

Per-User OAuth relies on lazy authorization:

1. Initial Tool Discovery: The client application connects to the MCP gateway using an initial identity token (such as a virtual key or an enterprise SSO session). The agent sees all available tool schemas.
2. Execution Trigger: The agent attempts to call a user-bound tool (for example, github_create_issue).
3. Session Interruption: The gateway checks its credential store for an active, valid token associated with both user_id and the github MCP server.
4. Consent Redirection: If no token exists, the tool call halts. The gateway returns a consent URL back to the host client.
5. Delegated Login: The human user opens the link in their browser, reviews the specific permission scopes requested by the tool, and approves access directly with the third-party provider (e.g., GitHub).
6. Token Anchoring: The gateway receives the authorization code, exchanges it for tokens, encrypts the credentials, and links them to that user's identity record. The agent then resumes execution, utilizing the newly minted, user-scoped token.

This guarantees that tool executions strictly reflect the actual permissions of the human operator. If an engineer lacks permission to write to a repository in GitHub, the MCP server rejects the agent's tool call with a standard 403 Forbidden.

5. Token Exchange (RFC 8693): Enterprise Single Sign-On and Identity Chaining

While Per-User OAuth provides robust isolation, forcing hundreds of enterprise employees to manually click through OAuth consent screens for dozens of internal MCP services introduces massive administrative friction.

In modern enterprise architectures, developers already authenticate to a central Identity Provider (IdP) like Okta, Microsoft Entra ID, PingFederate, or Keycloak. The ideal pattern is to propagate that authenticated identity seamlessly to all downstream internal MCP servers without storing long-lived static secrets or prompting users repeatedly.

This is achieved using OAuth 2.0 Token Exchange (RFC 8693).

How Token Exchange Operates in MCP

RFC 8693 defines a formal specification for a Security Token Service (STS). It allows a client or gateway to submit an existing, valid security token (the subject_token) in exchange for a brand-new token scoped specifically for a target resource server.

In an enterprise MCP deployment:

1. The developer authenticates against their enterprise IdP, acquiring a corporate JSON Web Token (JWT) representing their primary identity.
2. The developer launches their agent, which passes this user JWT to the MCP gateway.
3. The agent attempts to call an internal tool (e.g., query_financial_records).
4. Instead of storing a persistent access token, the gateway makes an on-the-fly RFC 8693 request to the enterprise STS:

POST /oauth/v2/token HTTP/1.1
Host: idp.enterprise.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&resource=https%3A%2F%2Fmcp-finance.internal.example
&audience=mcp-finance-service
&subject_token=eyJhbGciOiJSUzI1NiIsInR5cCI...
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token
&requested_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token

1. The STS validates the user's incoming corporate token, evaluates corporate access policies (such as group memberships and device compliance), and issues a short-lived (e.g., 5-minute), down-scoped access token specifically minted for the mcp-finance-service audience.
2. The gateway forwards the tool execution request to the internal MCP server with this newly minted token attached in the Authorization: Bearer header.
3. The internal MCP server validates the token's cryptographic signature, confirms the audience, and verifies that the calling user has explicit permission to execute the action.

Advantages of Token Exchange

• Zero Stored Upstream Secrets: Because tokens are requested on-behalf-of (OBO) the user at call time and expire within minutes, there is no database of long-lived access tokens to compromise.
• Cryptographic Nonce and Audience Binding: Following RFC 8707 Resource Indicators, the issued token is cryptographically bound to the target server URI. If an intermediate MCP server is compromised, the stolen token cannot be replayed against other internal servers.
• Immutable Enterprise Auditing: Downstream services log the actual corporate user identity encoded in the token's claims, satisfying SOC 2, HIPAA, and ISO 27001 compliance standards.

Centralizing Tool Security with an MCP Gateway

Managing these varied authentication models directly inside client software is unsustainable. If an organization has hundreds of engineers utilizing agents across Cursor, Claude Code, and internal applications, configuring every developer's machine with OAuth callbacks, secret vaults, and custom header transformations results in widespread configuration drift and severe credential exposure.

Deploying Bifrost as an intermediary control plane abstracts upstream authentication away from individual client runtimes.

+-----------------------------------------------------------------------------------+
|                            DEVELOPER WORKSTATION                                  |
|                                                                                   |
|  [Coding Agents / IDEs]                      [Bifrost Edge (Alpha)]               |
|  (Cursor, Claude Code) --------------> (Transparent Local Routing & Enforcement)  |
+-----------------------------------------------------------------------------------+
                                            |
                         Authenticated Gateway Connection
                         (Single Virtual Key / User Identity)
                                            |
                                            v
+-----------------------------------------------------------------------------------+
|                                  BIFROST GATEWAY                                  |
|                                                                                   |
|   +---------------------+   +---------------------+   +-----------------------+   |
|   | Virtual Key Control |   |  MCP Tool Filtering |   | Dynamic Token Engine  |   |
|   | (Budgets, Limits)   |   |  (RBAC Allow-Lists) |   | (OAuth 2.1, RFC 8693) |   |
|   +---------------------+   +---------------------+   +-----------------------+   |
+-----------------------------------------------------------------------------------+
        |                          |                                   |
        | Static Headers           | Per-User OAuth                    | Token Exchange
        v                          v                                   v
+------------------+     +--------------------+             +-----------------------+
| Internal DB MCP  |     | GitHub / Jira MCP  |             | Core Enterprise MCP   |
+------------------+     +--------------------+             +-----------------------+

Virtual Keys and Granular Tool Filtering

In Bifrost, administrators manage security policies using virtual keys. A virtual key acts as a secure surrogate credential presented by the agent client. Instead of handing raw upstream API tokens to developers or agent runtimes, the platform maps the virtual key to specific upstream permissions.

Beyond routing requests, Bifrost applies governance and security controls (virtual keys, budgets, guardrails, audit logs) centrally, and Bifrost Edge extends that same governance and security to AI traffic on employee machines, with endpoint enforcement on each device. This unified architecture prevents shadow AI by intercepting ungoverned tool invocations directly on workstation environments before requests reach sensitive networks.

Within this governance framework, administrators configure MCP tool filtering to restrict which tools a given virtual key can discover or execute. For example, a virtual key assigned to junior contractors can be restricted to read-only tools, while write-capable tools (e.g., delete_database_row) are dynamically omitted from the protocol's tools/list response.

For large-scale enterprise deployments, Bifrost Enterprise introduces MCP tool groups to bundle related server tools into logical collections, alongside MCP with federated authentication to automatically translate existing REST APIs into securely authenticated MCP interfaces without requiring manual middleware code. Every tool execution is captured in structured audit logs to ensure complete operational accountability.

Furthermore, when organizations need to manage tool usage on developer laptops, Bifrost Edge provides active MCP governance. Operating in alpha as an endpoint extension to the gateway control plane, Bifrost Edge discovers locally configured MCP servers across tools like Claude Desktop or Cursor, applies centralized allow/deny policies, and prevents unauthorized tool servers from executing locally.

Frequently Asked Questions

What is the standard authentication protocol for MCP?

The official Model Context Protocol specification establishes OAuth 2.1 as the recommended authentication standard for remote HTTP and SSE transports. It incorporates Authorization Server Metadata (RFC 8414), Dynamic Client Registration (RFC 7591), Protected Resource Metadata (RFC 9728), and mandatory PKCE challenge verifications.

How does MCP handle token expiration during agent tool calls?

When an access token expires during multi-step tool execution, a compliant MCP client or intermediate gateway intercepts the 401 Unauthorized response, executes a refresh token grant against the authorization server in the background, and retries the tool execution seamlessly without failing the broader agent workflow.

Can local STDIO MCP servers use OAuth authentication?

STDIO MCP servers communicate directly through operating system process pipes (stdin and stdout) and cannot natively initiate browser redirection loops or receive HTTP callbacks. They rely on environment variables passed by the host process rather than protocol-level OAuth.

What is the difference between server-level OAuth and per-user OAuth in MCP?

Server-level OAuth uses a single shared access token configured once by an administrator, meaning all callers execute tools under that shared identity. Per-User OAuth requires each individual caller to authenticate, linking distinct tokens to specific users so that upstream tools enforce personal access permissions.

How does RFC 8693 token exchange prevent credential leakage in MCP?

RFC 8693 token exchange eliminates the need to store persistent upstream credentials. When a tool call occurs, the gateway exchanges an incoming user identity token for a down-scoped, short-lived token cryptographically bound to the target server's audience, ensuring credentials cannot be replayed elsewhere if intercepted.

What happens if an MCP server rejects an unauthenticated request?

In accordance with RFC 9728, the MCP server responds with an HTTP 401 Unauthorized status code and includes a WWW-Authenticate header containing the URL of its Protected Resource Metadata document, directing the client to the appropriate authorization server.

Sources

• Model Context Protocol Authorization Specification - Official protocol specification defining OAuth 2.1 requirements, roles, discovery, and transport security rules for MCP implementations.
• RFC 8693: OAuth 2.0 Token Exchange - IETF standard specifying the HTTP and JSON Security Token Service framework for delegation and impersonation flows.
• RFC 9728: OAuth 2.0 Protected Resource Metadata - Internet standard for discovering authorization servers and security constraints directly from protected API resources.
• RFC 8414: OAuth 2.0 Authorization Server Metadata - Standardized JSON metadata specification for automated discovery of OAuth endpoints, scopes, and supported grant types.

Getting Started with Governed MCP Authentication

Implementing secure MCP authentication is fundamental to graduating autonomous agents from local prototypes into enterprise production environments. By choosing the appropriate pattern—moving from static headers to Per-User OAuth for third-party SaaS and RFC 8693 Token Exchange for internal zero-trust systems—organizations can protect sensitive data while maintaining comprehensive auditability.

Engineering teams evaluating how to unify tool access, enforce rate limits, and simplify token management across agent fleets can request a Bifrost demo or review the open-source repository to get started.