MCP Authentication

What it is

Establishing and proving, across a Model Context Protocol connection, who is on the other end and what they were granted. It covers how a connecting application identifies itself, how a human user's consent is obtained and represented, how the resulting credential is scoped and bound to the specific server it is presented to, and how all of that is renewed, re-consented, and revoked over a session that may outlive any individual token.

Why it matters

The protocol's useful servers sit in front of mailboxes, repositories, ticketing systems, and payment records. Whether a connection carries the end user's authority, the application's, or an administrator's determines what the far side can do and whose name appears in its audit log — and getting that wrong is not a degraded experience but an access-control failure. The long-lived, conversational shape of these connections makes it harder than a normal API integration: consent is given once, early, by someone who will not be watching when the hundredth call is made.

Authenticating a connection versus authorising a call

Authentication answers who the caller is and what envelope of authority they were granted when the connection was established. Deciding whether this specific invocation, with these arguments, is allowed right now is a separate evaluation that happens per call and can say no to a perfectly authenticated caller. The two are frequently conflated because a granted scope looks like a permission; the difference shows up the moment you need to deny one tool on a server whose scope the user has already consented to.

Key decisions

• Whether a remote server is its own protected resource with its own authorisation server, or defers entirely to an existing identity provider the organisation already runs. The second is almost always right and constrains what scopes can express.
• Whether the end user's identity reaches the backing system, or the server acts under a service identity and records the user only in its own logs. This choice cannot be revisited cheaply later.
• How a connecting application obtains client credentials: pre-registered per deployment, or registered dynamically at connection time. Dynamic registration removes a manual step and creates an endpoint that must be constrained.
• Credential scope granularity, and whether a scope maps to the whole server or to individual offerings on it. Server-wide scopes mean consenting to the least sensitive tool consents to the most sensitive one.
• What authenticates a locally spawned server, where there is no network peer and no token — process provenance, package signing, and the user's own privileges are all you have.
• What happens when a credential expires mid-conversation: a tool error the model tries to work around, or an explicit re-authorisation the user is asked to complete.
• How revocation propagates to a connection that is already open and already trusted.

Failure modes

• A server accepts a credential that was issued for a different audience, and an attacker who can get a token for one system uses it against another — the classic confused-deputy shape, and the single most consequential error in this capability.
• A client forwards the token it received from its own user straight through to a third-party API, so that API now holds a credential for your system.
• A shared static secret lives in a configuration file, is copied between developer machines, and ends up committed; nothing can attribute or revoke a single user's access.
• Consent is collected once with a description naming the server rather than the data, and the user has no idea they granted mailbox write access.
• Scopes are granted at connection level, so a connection established to read calendar availability can also cancel meetings.
• A refresh fails mid-session, the failure is returned as an ordinary tool error, and the model spends several turns attempting to work around an expired credential.
• A dynamic client registration endpoint is open to any caller, and the authorisation server accumulates client records nobody can account for.
• Access is denied by instructing the model not to call something, rather than by a check the model cannot talk its way past.
• A locally installed server runs with the user's full desktop privileges because nothing in the setup flow ever raised the question.

Related capabilities

• MCP Server — the protected resource a credential is presented to
• MCP Client — initiates the authorisation flow and holds the result
• MCP Gateway — where identity is commonly terminated and re-issued
• Tool Permission Management — the per-call decision this capability does not make
• Credential and Secret Management — storage, rotation, and custody of what is issued here

Applies: Production readiness · Design questions