MCP Authentication
Model Context Protocol (MCP) makes connecting AI agents to tools and data look deceptively simple.
A client discovers an MCP server, learns what tools it exposes and starts calling them.
The interesting part starts when the MCP server can do something that actually matters.
Read customer data. Create content. Approve something. Update a record. Trigger a workflow. Access a financial system.
At that point the question is no longer just what tools does this server expose?
It becomes:
Who is this agent acting for, what is it allowed to do, and where can its credentials be used?
This is where MCP authentication gets interesting.
An MCP server is an OAuth resource server
The first thing to understand is that MCP does not invent a new AI-specific identity system.
For HTTP-based MCP servers, the protocol builds on established OAuth standards. The MCP server acts as a protected resource server. The MCP client acts as an OAuth client. An authorization server authenticates the user and issues an access token for the MCP server.
User
|
v
MCP Client
|
| OAuth authorization
v
Authorization Server
|
| resource-bound access token
v
MCP Client
|
v
MCP Server
The authorization server might be Microsoft Entra ID, Auth0, another identity provider, or an authorization service operated by the platform itself.
The important point is that the MCP server and authorization server are separate roles.
The MCP server does not need to own the login experience. Its job is to validate that the access token presented to it is valid and intended for that resource.
Authentication starts with discovery
An MCP client should not need hard-coded knowledge of how every server authenticates.
A protected server can return a 401 Unauthorized response and identify its protected-resource metadata endpoint using the WWW-Authenticate header.
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer
resource_metadata="https://cms.example.com/.well-known/oauth-protected-resource"
The client retrieves that metadata and discovers which authorization server protects the MCP resource.
From there, normal OAuth discovery provides information such as the authorization endpoint, token endpoint and supported capabilities.
This is a small architectural detail, but an important one.
Authentication becomes discoverable rather than something every MCP client and server pair has to configure manually.
The access token is for the MCP server
One of the most important parts of the MCP authorization model is resource binding.
When a client requests authorization, it identifies the MCP server as the resource it wants to access.
resource=https://cms.example.com/mcp
The resulting access token should therefore be intended for that MCP resource.
Token for CMS MCP
|
v
CMS MCP Server
✓
It should not be possible to take a token intended for another service and simply pass it to an MCP server.
Microsoft Graph token ---> CMS MCP Server
X
This is more than tidiness.
Resource-bound tokens reduce the risk of audience confusion and confused-deputy problems, where a token issued for one system is incorrectly accepted by another.
Token passthrough is not the answer
This becomes especially important when the MCP server itself needs to call another protected service.
Imagine an MCP server that can read customer data from a CRM and then create a document in another application.
A tempting implementation is to accept the user's token and simply pass that same token downstream.
User token
|
v
MCP Server
|
+----> CRM
|
+----> Document API
That is not the model MCP is trying to encourage.
The token presented to the MCP server is supposed to be for the MCP server.
If the MCP server needs to call another protected API, it should obtain the appropriate credential or token for that downstream service.
That keeps the security boundaries explicit:
User
|
v
MCP Client
|
| Token A: for MCP Server
v
MCP Server
|
| Token B: for downstream API
v
Downstream API
As MCP starts being used for enterprise automation rather than simple data retrieval, this distinction becomes increasingly important.
Authentication is not the same as tool authorization
OAuth can tell the MCP server who the user is acting as and what scopes have been granted.
That does not mean an authenticated agent should automatically be able to call every tool.
Consider a content-management MCP server exposing these tools:
search_content
get_content
create_content
update_content
publish_content
A useful authorization model might have scopes such as:
cms.content.read
cms.content.create
cms.content.edit
cms.content.publish
Those permissions can then determine which operations are actually available to the current session.
User A
search_content ✓
get_content ✓
create_content X
publish_content X
User B
search_content ✓
get_content ✓
create_content ✓
update_content ✓
publish_content X
User C
search_content ✓
get_content ✓
create_content ✓
update_content ✓
publish_content ✓
This creates an important architectural boundary.
The agent decides what it wants to do. The security layer decides what it is allowed to do.
That sounds obvious, but it is easy to blur when an LLM is making the decision about which tool to invoke.
The model should never be the authority on whether the model is authorised.
What changed in July 2026?
The July 2026 MCP specification hardened a number of areas that start to matter once MCP moves beyond demos.
Issuer validation
Authorization responses can include an iss issuer identifier, and clients validate that the response came from the authorization server they originally selected.
This protects against authorization-server mix-up attacks, where a client can otherwise become confused about which authorization server issued a response.
Credentials belong to an authorization server
Client credentials must be associated with the authorization server that issued them.
A client should not obtain credentials from one authorization server and casually reuse them with another.
MCP Server A ---> Authorization Server A
|
Client ID
|
+----> Authorization Server B
X
If the authorization server changes, the client needs the appropriate registration or client identity for the new issuer.
Native client handling
The July changes also tightened client registration behaviour for native applications such as desktop clients and command-line tools, where localhost redirect URIs are common.
This matters because MCP clients are not just web applications. They may be desktop applications, developer tools, IDE integrations or local agent runtimes.
Moving beyond Dynamic Client Registration
Another significant direction in the July release is the move away from treating Dynamic Client Registration as the long-term answer for every MCP integration.
Client ID Metadata Documents provide a more declarative mechanism for identifying OAuth clients and their metadata, while Dynamic Client Registration remains available for compatibility.
This is the sort of protocol evolution that is easy to overlook, but it reflects MCP maturing from a developer-oriented protocol into something expected to operate across many different clients, servers and identity providers.
PKCE matters
MCP clients are also expected to use Proof Key for Code Exchange (PKCE) as part of the authorization-code flow.
PKCE was originally designed to protect public clients that cannot safely store a client secret, which describes many MCP clients very well.
A desktop application, CLI tool or local AI client should not be treated like a confidential server-side web application.
The broader security model also relies on established OAuth practices such as HTTPS, constrained redirect URIs, short-lived access tokens and appropriate refresh-token handling.
The important point is that MCP is not inventing new answers to problems OAuth has spent years solving.
MCP Authentication
|
+-- OAuth 2.1
+-- Bearer Tokens
+-- Authorization Server Metadata
+-- Resource Indicators
+-- Protected Resource Metadata
+-- Authorization Server Issuer Identification
+-- PKCE
That is exactly the right direction.
The harder problem is agent identity
Even with all of this, there is a bigger problem waiting behind OAuth.
Most authentication systems were designed around a fairly clear model:
Human
|
v
Application
|
v
Protected Resource
AI agents complicate that model.
Consider an agent running a long-lived workflow:
Tony
|
| delegates authority
v
Agent A
|
+----> CMS MCP
|
+----> CRM MCP
|
+----> Finance MCP
|
+----> Agent B
Who is Agent A?
Is it Tony?
Is it its own workload identity?
Is it Agent A acting on behalf of Tony?
If it delegates work to Agent B, what authority should Agent B inherit?
How long should that delegation survive?
Can it be revoked independently of Tony's own access?
These questions become even more important when an agent operates asynchronously and the user is no longer sitting in front of a browser approving each action.
Human permissions should not automatically become agent permissions
This is where I think enterprise implementations need to be particularly careful.
A user may have permission to perform a sensitive action because the organisation trusts that person to apply judgement before doing it.
That does not automatically mean an AI agent acting on their behalf should inherit the same authority.
Human permissions
!=
Agent permissions
For example:
Tony
Read content ✓
Create content ✓
Edit content ✓
Publish content ✓
Tony via AI Agent
Read content ✓
Create content ✓
Edit content ✓
Publish content confirmation required
That distinction will matter more as agents move from recommendation to execution.
An enterprise agent may eventually need several overlapping identities:
- the identity of the human on whose behalf it is acting;
- its own workload or application identity;
- the scopes explicitly delegated to this particular agent;
- policy constraints around particular tools or actions;
- and potentially a separate delegation chain when one agent invokes another.
OAuth provides much of the underlying machinery, but enterprise policy still needs to determine what delegated AI authority actually means.
MCP makes connectivity easy. Security remains an architectural problem.
MCP is often described as USB-C for AI.
That analogy works reasonably well for connectivity.
It works much less well for security.
A USB device does not normally decide to use three other devices, retrieve customer data, create a contract and then delegate part of the task to another autonomous process while its user is asleep.
Connecting an agent to a tool is the easy part.
The harder questions are:
- Who is the agent acting for?
- What resource is the token actually valid for?
- Which tools can the agent invoke?
- Which actions require additional approval?
- What identity does an autonomous agent have when the user is absent?
- What authority can one agent delegate to another?
The July 2026 MCP specification does not solve all of those enterprise authorization questions.
What it does do is continue putting much stronger identity and authorization foundations underneath the protocol.
That matters because MCP is rapidly moving beyond read-only integrations.
As agents gain the ability to take real actions, authentication stops being protocol plumbing and becomes part of the core architecture of the agent itself.