MCP Authentication Explained: OAuth, Hooks, and the July 2026 Update

MCP authentication is the OAuth-based handshake that lets an AI agent connect to a remote Model Context Protocol (MCP) server without that agent ever holding the server’s actual credentials: the agent gets a short-lived, server-scoped token instead of a shared password. For a security team evaluating AI agents, this is the short answer to what “MCP authentication” means. It is also a term that gets confused constantly with a completely different mechanism, Claude’s Agent SDK hooks, and that confusion is exactly what’s showing up in search right now.

The short version

• MCP’s authorization model is built on OAuth, not on an agent holding a server’s raw credentials.
• An MCP server publishes an OAuth 2.0 Protected Resource Metadata (RFC 9728) document, so a client can discover the right authorization server automatically instead of being configured by hand.
• Resource Indicators (RFC 8707) bind a token to one specific MCP server, so a stolen token cannot be replayed against a different one.
• The Model Context Protocol’s 2026-07-28 spec update tightened this further: authorization servers now include an issuer identifier that clients must validate, and Client ID Metadata Documents (CIMD) are now preferred over the deprecated Dynamic Client Registration (DCR) for proving who a client is.
• None of this is the same thing as Claude’s Agent SDK hooks (PreToolUse, PostToolUse, and the rest), a separate mechanism for intercepting what an AI agent does once it is already connected, which is where a lot of “MCP hooks authentication” searches actually want to land.
• Authentication decides whether a connection is allowed to exist. It doesn’t inspect what a specific request carries. That’s a different job, the one an MCP Gateway does.

What is MCP authentication, and why does it matter to security teams?

Before the Model Context Protocol had a standard authorization model, connecting an AI agent to an internal tool often meant the agent, or the person wiring it up, holding a real credential for that tool: an API key pasted into a config file, or a service account password baked into a connector. That’s a liability the moment the agent, the config file, or the machine it runs on is compromised.

MCP’s authorization specification replaces that with OAuth. When an agent tries to connect to an MCP server for the first time, it gets redirected to that server’s own authorization server, where a person authenticates directly using whatever identity provider is already in place. The agent never sees that password. It receives back a short-lived access token, scoped to that one server, and presents the token on every subsequent request instead.

For a CISO, the practical effect is that “is this MCP connection authenticated” is the wrong question to worry about day to day, because the protocol already answers it. The real question is what an authenticated agent does once it’s connected, which authentication alone cannot tell you. For the broader risk picture beyond authentication, see MCP Security: A CISO’s Guide to Agent-Tool Risk.

How does a client find the right authorization server?

Every MCP server that requires authentication publishes an OAuth 2.0 Protected Resource Metadata document (RFC 9728). It’s a small, standard JSON document at a well-known location on the server, and it tells a connecting client which authorization server actually protects this resource.

Without this, every new MCP server a business adopts would need its authorization endpoint configured by hand, which is exactly the kind of manual step that gets skipped under deadline pressure. With it, a properly built MCP client can discover the right authorization server on its own the first time it encounters a new server, which is part of why MCP adoption spread as fast as it did across Claude, ChatGPT, and Cursor. For what that speed means for the rest of the business, see What Is an MCP Gateway? A Security Team’s Guide.

What stops a stolen MCP token from being replayed somewhere else?

This is what Resource Indicators (RFC 8707) are for. When a client requests an access token, it includes a resource indicator naming the exact MCP server the token is for. The authorization server then issues a token whose audience is restricted to that one server.

Practically, this means a token issued for your internal ticketing system’s MCP server is useless against your customer database’s MCP server, even if both happen to trust the same identity provider. Without audience restriction, a single stolen token could be replayed against anything the issuing authorization server protects, turning one leak into an open door across every connected tool.

What changed in the Model Context Protocol’s July 2026 update?

The 2026-07-28 specification revision didn’t introduce OAuth to MCP. It tightened the authorization model that was already there. Three changes matter most for a security team evaluating MCP-connected AI agents:

Area	Before the July 2026 update	After the July 2026 update
Client registration	Dynamic Client Registration (DCR, RFC 7591) was the standard way a client registered itself with an authorization server	DCR is deprecated in favor of Client ID Metadata Documents (CIMD), though DCR still works for backwards compatibility with authorization servers that haven’t adopted CIMD yet
Authorization response	No requirement to confirm which authorization server actually issued a response	Authorization servers should include an issuer identifier (RFC 9207), and clients must validate it against the recorded issuer before redeeming an authorization code, closing a mix-up attack where a response from one server is mistaken for another’s
Client credentials	No explicit rule on whether a client could reuse a credential across different authorization servers	Client credentials must be keyed to the specific authorization server that issued them, must not be reused with a different one, and must be re-registered if the authorization server changes

The net effect is a tighter, less ambiguous handshake, not a new requirement most security teams need to act on directly. It matters more for whoever builds or operates an MCP client or server than for the CISO deciding whether to approve one, but it’s worth knowing the direction: every revision since MCP introduced OAuth has removed ambiguity from the authorization flow, not added optional steps.

Why do people searching for “MCP hooks authentication” usually mean something else?

This phrase shows up in search, and it’s almost always two unrelated things getting merged into one query. MCP authentication, everything above, decides whether an agent’s connection to a remote MCP server is allowed to exist. Claude’s Agent SDK hooks are a completely different mechanism: callback functions such as PreToolUse and PostToolUse that let a developer intercept what an already-connected agent does inside a single session, for example blocking a specific tool call or logging it for an audit trail.

Neither one is “hooks authentication.” A hook doesn’t authenticate anything, it intercepts an event that already happened inside an authenticated session. And MCP’s OAuth model doesn’t use hooks at all. The two sit at different layers: authentication is about the connection, hooks are about what happens during it.

This is also where Anthropic’s own Claude Enterprise feature, Inference Hooks, adds a third term to the pile, a security-specific callback that inspects a prompt before Claude processes it, built on a similar idea to Agent SDK hooks but a distinct product. See MCP Gateway vs. Inference Hooks: Two Deployment Options and Anthropic Inference Hooks: What Security Teams Need to Know for how that one actually works.

	MCP authentication	Claude Agent SDK hooks
What it decides	Whether a connection to an MCP server is allowed to exist	What happens to a specific tool call or event inside an already-connected session
Mechanism	OAuth 2.1, Protected Resource Metadata, Resource Indicators	Callback functions (PreToolUse, PostToolUse, SessionStart, and others) registered in agent code
Runs once per	Connection	Tool call or lifecycle event
Who typically configures it	The MCP server operator and the authorization server	The developer building the agent
Does it inspect request content?	No, it authenticates the connection itself	Yes, a hook callback can read and act on the specific tool call’s arguments

Does OAuth make an MCP connection safe by default?

No, and this is the gap that matters most for a CISO. OAuth answers “is this agent allowed to talk to this server at all.” It says nothing about what a specific, already-authenticated request is actually carrying. An agent with a validly issued, correctly scoped token can still make a request that pulls a spreadsheet of customer records, and MCP’s authorization layer has no opinion on that, because authenticating the connection was never its job.

That’s the layer an MCP Gateway exists for: reading the content of each authenticated request in real time and deciding whether to allow it, redact the sensitive part, hold it for a person, or block it outright. Authentication and inspection are two different controls, and an organisation needs both. For the full breakdown of what that second layer has to do, see What Is an MCP Gateway? A Security Team’s Guide.

What should security teams actually do about this?

Three practical steps, none of which require touching the Model Context Protocol’s own code:

1. Ask your MCP client vendors whether they support Client ID Metadata Documents. It’s the direction the specification is moving, and a client still solely reliant on Dynamic Client Registration will need to migrate eventually, even if DCR keeps working for now.
2. Don’t treat “this connection is authenticated” as “this connection is safe.” Authentication is necessary and was never meant to be sufficient. Every AI agent connection that matters still needs something watching what the request actually contains.
3. Get visibility into every MCP connection your business has made, approved or not, before writing a policy about any of them. For how that visibility question plays out in practice across a whole organisation, see MCP Security: A CISO’s Guide to Agent-Tool Risk and Shadow AI: What It Is and How to Control It.

Key takeaways

• MCP authentication is an OAuth-based handshake: a short-lived, server-scoped token, not a shared password an agent holds.
• Protected Resource Metadata (RFC 9728) lets a client find the right authorization server automatically. Resource Indicators (RFC 8707) stop a stolen token being replayed against a different server.
• The July 2026 spec update tightened this model with issuer validation and Client ID Metadata Documents, rather than introducing OAuth from scratch.
• “MCP hooks authentication” usually means two different things people are merging into one search: MCP’s own OAuth model, and Claude’s Agent SDK hooks, which intercept events inside an already-connected session.
• Authentication decides whether a connection exists. It doesn’t inspect what a request carries. That’s what an MCP Gateway is for, and most organisations running AI agents need both.

If you want to see what’s actually connecting to your data over MCP, authenticated or not, book a demo of Metomic.