MCP authentication: how authorization works for AI agents
Under the current MCP specification (2026-07-28), authorization is optional, and how you do it depends on the transport. HTTP servers should use the spec's OAuth 2.1 flow. Local stdio servers should get credentials from the environment instead.
Which approach applies
| Transport | What the spec says | In practice |
|---|---|---|
| HTTP | Should conform to the authorization spec | OAuth 2.1, with the server acting as a protected resource |
| stdio | Should not follow it, and should retrieve credentials from the environment | Environment variables or a local secret store |
| Other | Must follow established security practice for that protocol | Depends on the protocol |
The HTTP flow
- The client calls the MCP server without a valid token and is told authorization is required.
- The client reads the server's Protected Resource Metadata (RFC 9728) to find its authorization server. MCP servers must implement this.
- The client discovers the authorization server's endpoints through its OAuth or OpenID Connect metadata.
- The client identifies itself, preferably with a Client ID Metadata Document. Dynamic Client Registration is now deprecated and kept only for backward compatibility.
- The client runs the OAuth flow and includes the
resourceparameter (RFC 8707) in both the authorization and token requests, naming the server the token is for. - The client calls the MCP server with that token, and the server checks that it was issued for that server.
The rules that are easy to get wrong
Don't pass tokens through. The spec is explicit: clients must not send a server any token other than one issued by that server's authorization server, and servers must not accept or transit any other tokens. If your server calls a third-party API, it needs its own credential for that API. Forwarding the token it received isn't allowed.
Validate the audience. A token issued for one server shouldn't work on another. Without this check, a malicious or compromised server could replay a token it received against other services.
Keep secrets out of the model's path. Elicitation lets a server ask the user for input during a task, but the spec forbids using form mode to request passwords, API keys, access tokens or payment credentials. Those interactions must use URL mode, which sends the user to an external page so the secret doesn't pass through the MCP client.
URL mode comes with its own rules. Clients must show the full URL and get consent before opening it, and they can't pre-fetch it. Servers can't put sensitive information about the user in the URL, and they must verify that the person who opens it is the right user.
Agent identity is a separate question from human approval
OAuth answers "is this client allowed to act on this user's behalf?" It doesn't answer "does the person agree to this specific action, right now?" A token that's valid for an hour will happily authorize a wire transfer the human never saw.
For high-stakes actions, you need a second check at the moment of action:
- The agent requests approval for one specific, described action.
- The human confirms on a separate page, outside the agent's context.
- The agent gets back an approved or denied result, and never sees the secret that proved it.
It's the same shape as the OAuth device flow, and it's also why URL-mode elicitation exists.
What we're building
That approval step is what Palace Verify is for. It's a pay-per-use verification service we're developing for agents: no user accounts, secrets checked against on-chain commitments, and revocation, expiry and use limits. The MCP tools and human confirmation flow aren't available yet, so this page is a design note, not a product you can use today. Email us if your agents need this and you'd like to talk about what you need it to do.