Describe the flow in four facts: how a client proves who it is (for remote servers, OAuth with PKCE), who the token is issued for (the specific server), how long it lives, and how you revoke it. For local stdio servers, say credentials come from the environment and explain how those are stored.
What the specification says
The MCP authorization specification sets the baseline reviewers have in mind. It says clients must implement PKCE, that clients must use the resource parameter from RFC 8707 to name the server a token is for, and that servers must validate that tokens were issued specifically for them. Invalid or expired tokens get an HTTP 401. It also says authorization servers should issue short-lived access tokens, and that refresh tokens for public clients must be rotated.
If you built your server to that text, your answer writes itself. If you did not, find out now, before a reviewer does.
Remote server answer, step by step
- Flow. "Remote MCP access uses OAuth 2.1 with PKCE. Users sign in through our identity provider."
- Audience. "Tokens are bound to our MCP server through the resource parameter and validated on every request."
- Lifetime. State the actual access token lifetime and whether refresh tokens rotate.
- Revocation. Say who can revoke, how fast it takes effect, and whether it is logged.
- Transport. All endpoints over HTTPS. The specification requires that for authorization server endpoints.
Keep numbers real. If a token lasts an hour, write an hour.
Local server answer
The stdio transport usually has no OAuth flow. Credentials are passed through environment variables or a config file. A reviewer will ask where those live. Good answers say: a per user token, not a shared one; stored in the operating system keychain or a secrets manager; excluded from version control; scoped to the minimum needed. See why stdio servers use environment credentials.
Two things not to claim
- "We use session IDs for security." The MCP security guidance says servers must not use sessions for authentication. A session ID identifies a conversation, not a person.
- "We pass the user's token to the downstream API." The specification calls token passthrough an anti-pattern and says it is forbidden. If your server calls another API, it needs its own token for that API.
A compact answer you can adapt
"Remote access uses OAuth 2.1 with PKCE. Tokens are issued for our MCP server as the audience and are validated on each request. Access tokens are short lived, refresh tokens rotate, and an administrator can revoke a client at any time. The server does not forward client tokens to other services. Local use authenticates with per user tokens held in the OS keychain."
Edit it until every sentence is true of your system. The honest gaps deserve a dated plan.
Safeguard has a free scan and an MCP Guardrail for controlling agent tool use, and compliance and evidence automation helps keep the authentication records together for the next questionnaire.
Quick check
Is an API key acceptable for an MCP server?
It can be, especially for local use, if it is per user, scoped, rotated and stored safely. Say that, and say why you chose it over OAuth.
What evidence should we attach?
A short diagram of the flow, the token lifetime settings and the revocation procedure. Redact client identifiers and endpoints you do not want shared.
Sources
Last reviewed: 19 October 2026.
