# The MCP auth production checklist - Published: 2026-07-31 - Tag: SECURITY - URL: https://authplane.ai/blog/mcp-auth-production-checklist/ - Excerpt: An eight-point production checklist for MCP server authorization: discovery, tokens, scopes, refresh, key rotation, identity, audit, and client registration, each with a pass test. --- *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](https://astrix.security/learn/blog/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](https://github.com/AuthPlane). ## Sources 1. MCP Authorization specification, 2026-07-28 (current version). 2. Model Context Protocol, The 2026-07-28 Specification (release announcement, DCR deprecation). 3. RFC 9728, OAuth 2.0 Protected Resource Metadata. 4. RFC 8707, Resource Indicators for OAuth 2.0. 5. Astrix Security, State of MCP Server Security 2025.