Every other authorization topic for MCP assumes something that most teams have not actually decided: which authorization server issues the tokens your MCP server accepts. The specification is clear that the MCP server is a resource server and that it should not be its own authorization server. It does not tell you whether that authorization server is your product's existing login system, your enterprise identity provider, a managed service, or something you stand up yourself.
This decision sets the ceiling on everything downstream: whether you can bind tokens to a resource, whether clients can register themselves, whether a customer's security team can revoke access centrally. Make it in week one. Changing it in week five means rewriting discovery, token validation, scope definitions, and the evidence pack.
What the role actually requires
Before comparing options, write down what the authorization server has to do for an MCP deployment. The short list, in RFC terms:
- OAuth 2.1 authorization code flow with PKCE for every client, public or confidential.
- Resource indicators (RFC 8707). The client sends
resourceon the authorization and token requests; the authorization server must honour it and issue a token whose audience is your MCP server. Without this you cannot do audience validation, and a token minted for another API will be presented to yours. - Authorization server metadata (RFC 8414) at a discoverable URL, so the client can find the endpoints your protected resource metadata points at.
- Dynamic client registration (RFC 7591), or a documented alternative. MCP clients you have never heard of will try to connect. If you disable DCR, you need a client identity story — client ID metadata documents, a pre-registration process, an allowlist — and you need it written down for reviewers.
- Refresh token rotation and revocation (RFC 7009), plus a path from "admin disables the user" to "agent loses access" in minutes, not at token expiry.
- Introspection (RFC 7662) or published JWKS so your server can validate the token itself.
- Audit events on the authorization side: issuance, consent, refresh, revocation, with the same correlation identifiers your tool-call audit uses.
Anything on that list the candidate cannot do becomes work you carry in your own code, forever, and a paragraph you have to defend in a questionnaire.
Option one: your product's existing login system
Many B2B SaaS products already have an OAuth authorization server for their public API. Reusing it is the shortest path to a single consent experience and a single place to revoke.
It fails on two common points. First, API authorization servers built for server-to-server integrations frequently issue tokens with a fixed audience and ignore resource; they were never asked to mint a token for a second resource. Second, their scope model is usually coarse — one api scope, or per-endpoint scopes that do not map to agent-visible tools. Check both before you commit. If the authorization server is a library inside your monolith, also check who owns it, because you are about to ask that team for RFC 8707 support on your timeline.
Option two: a managed authorization server
Auth0, Okta, Entra ID, Keycloak, Ory, WorkOS and similar products can all act as the authorization server for a resource. They give you metadata, JWKS, rotation, and an admin surface a customer's security team recognises, which is worth real time in a review.
Verify, per product and per plan, three things that differ widely: whether resource indicators are supported and how the audience is populated; whether dynamic client registration can be enabled with a policy rather than all-or-nothing; and whether token exchange (RFC 8693) is available, because you will want it the moment your tools call a downstream system. Features and plan boundaries move, so test them against your own tenant rather than trusting a comparison table — including ours.
Option three: the customer's identity provider
For a single-tenant deployment inside an enterprise, the customer's IdP issuing the tokens is often the correct answer, and increasingly the one their security team asks for. Users get conditional access, group-based entitlements, and central revocation. Cross-app access patterns, where the IdP brokers which agent may reach which resource, assume this shape.
The cost is multiplicity. Each customer's IdP is a separate issuer with its own JWKS, its own claim names, its own group representation, and its own willingness to register your clients. Your server needs issuer-aware trust configuration, not one hard-coded issuer, and an onboarding runbook per tenant. For a multi-tenant SaaS MCP server, this is usually too much; for a governed internal platform, it is usually right.
Option four: building your own
Do not, unless identity is your product. An authorization server is a long-lived security component with a wide specification surface and a steady flow of errata. Writing one to pass a vendor review is a project in its own right, and the reviewer will ask who audits it. The one defensible version is a thin façade in front of a real authorization server — for example to add a consent screen that explains tools in your product's language — where the façade issues nothing and signs nothing.
Where the boundary goes
Whatever you pick, keep the split clean. The MCP server validates tokens and enforces policy; it does not issue, store, or refresh them. Specifically:
- The MCP server exposes protected resource metadata naming the authorization server, and returns
WWW-Authenticatewith that pointer on a 401. - The MCP server never sees user credentials and never proxies the token endpoint.
- Scope definitions live in one place — the authorization server's catalogue — and the MCP server's enforcement table references the same names.
- Downstream calls use token exchange, not the incoming token.
If you find the MCP server growing code that mints or refreshes credentials, the boundary has moved and the threat model needs redrawing.
What to write down
Reviewers ask who issues the tokens and how trust in that issuer is configured. Have a page ready that states: the issuer URL and metadata location; how keys are fetched, cached, and rotated; which claims are required and what happens when one is missing; whether DCR is open, policy-gated, or closed, and why; the revocation path and its measured latency; and the audit events emitted on the authorization side with retention. That page is a standard part of the evidence pack and it takes an afternoon to write once the decision is made.
The test that settles it
Pick the candidate, then run one end-to-end check before the architecture is fixed. Register a client dynamically if you intend to allow that. Complete an authorization code flow with PKCE and a resource parameter naming your MCP server. Inspect the token: confirm the audience, the issuer, the scopes, and the subject. Call a tool with it. Then call a tool with a token minted for a different resource and confirm a 401 with the right metadata pointer. Finally, disable the user and time how long the agent keeps working.
Five steps, half a day. If any of them cannot be made to pass, you have the answer, and you have it in week one rather than in the customer's review.
We make this decision in the design phase of every server build and check it first in an MCP security audit. If you have already picked one and want a second opinion before the build, tell us what you chose.