All posts
SECURITY
The MCP auth production checklist — cover art

The MCP auth production checklist

Eight things to verify before you put an authenticated MCP server in production. Each one has a test, so you can prove it rather than assume it.

TL;DR

  • This is a vendor-neutral pre-flight list. Every item is something you should verify regardless of what authorization server you run.
  • Each check is written as: what to verify, why it matters, and how you know you passed. If you cannot describe the passing test, treat the item as failing.
  • The eight areas: discovery, tokens, scopes, refresh and revocation, key rotation, identity, audit, and client registration.

Getting an MCP server to authenticate at all is the easy 80%. The last 20%, the part that survives a security review, is a set of specific behaviors that are easy to skip and hard to add back later. This checklist is that 20%. It is deliberately not AuthPlane-specific: work through it against whatever you run. We only appear at the end, as one way to satisfy the list.

Context for why this matters: Astrix Security's State of MCP Server Security 2025 found that of 5,200+ MCP servers analyzed, only 8.5% used OAuth and more than half relied on long-lived static keys. Most servers would fail item two below on the first try.

1. Discovery

Your MCP server must publish Protected Resource Metadata (RFC 9728) at the exact well-known path, and the authorization server it points to must be reachable and expose its own metadata. Clients rely on this to find where to authenticate without manual configuration.

Pass test: MCP Inspector completes discovery against your server with no hand-entered endpoints. It reads the 401, follows the resource_metadata pointer, finds the authorization server, and proceeds.

2. Tokens

Tokens must be audience-bound to your server's identifier, and their lifetime must be a deliberate choice rather than a library default. Audience binding is what stops a token minted for one MCP server from working against another.

Pass test: present a token whose audience is a different server. Your server rejects it. And you can state your token lifetime and the reason you chose it.

3. Scopes

Scopes should be enforced per tool, not per server. "This agent can reach this server" is not access control. "This agent can call read_db but not write_db" is. Blanket access is the difference between a compromised agent that can read and one that can delete.

Pass test: a token scoped for a read-only tool is refused when it calls a write tool, and the refusal happens at the server, not by convention.

4. Refresh and revocation

Refresh tokens should rotate on every use, and a replayed (already-used) refresh token should revoke the entire token family. This turns a token theft into a detectable event: the moment the stolen token is replayed, the family dies and the legitimate client is forced to re-authenticate, which is your signal.

Pass test: replay a rotated refresh token and confirm the family is revoked. You can point to the log entry where the replay was caught.

5. Key rotation

Signing-key rotation must be non-breaking. Your JWKS endpoint should serve both the current and the previous key during the rotation window, so tokens signed just before a rotation still validate just after it. A rotation that invalidates in-flight tokens is an outage waiting for a deploy.

Pass test: rotate keys in staging under live traffic. No request returns a 401 as a result of the rotation.

6. Identity

Every call should be attributable to both a user and an agent. When an agent acts on a user's behalf, and especially when one agent delegates to another, the token should carry that chain. Without it, row-level security, per-user rate limits, and multi-tenant isolation are all impossible, because the server literally does not know who is calling.

Pass test: from the audit log alone, you can answer "which agent made this call, on whose behalf, through which delegation chain" without guessing.

7. Audit

Token issuance, consent decisions, delegation hops, and revocations should all be logged and queryable, with a retention setting you chose deliberately. This is the artifact SOC 2 and HIPAA reviews actually ask for, and the thing you will wish you had the first time an agent does something it should not have.

Pass test: you can produce the full trail for a given token, from issuance to revocation, without shipping a code change to do it.

8. Client registration

You should have chosen deliberately between pre-registration, Client ID Metadata Documents (CIMD), and Dynamic Client Registration (DCR), and be able to say why. As of the 2026-07-28 spec, DCR is formally deprecated in favor of CIMD. It still works for backward compatibility and will be removed in a future version, so new deployments should treat the real choice as pre-registration when your clients have a prior relationship with your server, and CIMD when they do not. The right answer depends on that relationship.

Pass test: you can state, in one sentence, which registration approach you use and why, and if you still rely on DCR, that you know it is deprecated and have a path off it. "Whatever the library defaulted to" is a failing answer.

How AuthPlane maps to the list

AuthPlane is one way to satisfy these eight items without assembling them yourself. It issues audience-bound, short-lived tokens with tool-level scopes, rotates refresh tokens with family revocation on replay, serves current-plus-previous keys through rotation, carries agent identity and the delegation chain in every token, and writes issuance, consent, delegation, and revocation to a queryable audit log. It is validated against MCP Inspector with an automated end-to-end suite. Whether you use it or not, the checklist stands on its own.

The bottom line

If you can run every pass test above and point to the evidence, your MCP server is genuinely production-ready on the auth side. If any item is "we think so" rather than "here is the test that proves it," that is the item to fix first. Grab a runnable authorization server that clears the list out of the box: github.com/AuthPlane.

Sources

  1. MCP Authorization specification, 2026-07-28 (current version). https://modelcontextprotocol.io/specification/2026-07-28
  2. Model Context Protocol, The 2026-07-28 Specification (release announcement, DCR deprecation). https://blog.modelcontextprotocol.io/posts/2026-07-28/
  3. RFC 9728, OAuth 2.0 Protected Resource Metadata. https://datatracker.ietf.org/doc/html/rfc9728
  4. RFC 8707, Resource Indicators for OAuth 2.0. https://www.rfc-editor.org/rfc/rfc8707.html
  5. Astrix Security, State of MCP Server Security 2025. https://astrix.security/learn/blog/state-of-mcp-server-security-2025/