Auth-ready MCP servers expose the real identity control gap

At a glance

What this is: This is a developer guide on building an auth-ready MCP server, with the main finding that OAuth issuance, discovery, and JWT claim enforcement are the real governance layer for tool access.

Why it matters: It matters because IAM, PAM, and NHI teams need to treat MCP servers as identity-aware integration points where claims, scopes, and client registration determine whether AI-assisted tool use stays controlled.

👉 Read Descope's guide to building an auth-ready MCP server with Next.js

Context

MCP servers expose tools to AI assistants, but the security problem is not the tool code itself. The real question is who can invoke those tools, what identity proof they present, and how permissions are translated into request-time enforcement across NHI and agentic access paths.

That is why auth-aware MCP design now sits at the intersection of IAM, NHI governance, and application security. A server that relies on shared credentials or opaque service access cannot provide the accountability, scope control, or request-level traceability that practitioners need when assistants act on behalf of users.

Key questions

Q: How should teams enforce least privilege in MCP servers?

A: Use OAuth scopes as the primary access boundary, then verify the JWT locally at request time and reject any tool call whose claims do not match the tool’s required permissions. Least privilege works best when scopes are narrow, auditable, and mapped to specific tools rather than to broad application access. The authorization server should issue the claims, and the MCP server should enforce them.

Q: Why do MCP servers need external authorization servers instead of managing auth themselves?

A: External authorization servers reduce role confusion and align MCP with established enterprise identity patterns. When the MCP server also issues tokens, it becomes harder to prove who authenticated, who authorized, and which resource the token was meant for. Separation keeps trust boundaries explicit and makes delegated access easier to govern.

Q: What breaks when MCP tool access is not default-deny?

A: Tool discovery and invocation become open-ended privilege expansion paths. Without default-deny controls, teams cannot reliably prove which tools an agent can reach, which scopes were granted, or whether those calls were logged in a way that supports audit and incident review.

Q: Who is accountable for access decisions in an auth-aware MCP design?

A: Accountability is split. The authorization server is accountable for issuing valid claims and the MCP server is accountable for enforcing them at the tool boundary. Security teams should document that split clearly, because audit evidence, troubleshooting, and incident review all depend on knowing which system granted authority and which system consumed it.

Technical breakdown

OAuth and OIDC as the control plane for MCP access

MCP clients connect over OAuth, which means the server has to rely on an authorization server for token issuance, discovery metadata, and audience binding. In this pattern, the MCP server does not authenticate the client by itself. It verifies signed JWTs locally against a JWKS endpoint and then uses the claims inside the token to decide whether a tool call is allowed. That separation matters because it turns tool access into a governed identity workflow rather than a hard-coded application rule.

Practical implication: treat the authorization server, discovery document, and JWKS validation path as part of your identity architecture, not as app plumbing.

Claim-based tool gating for scopes, roles, and email

The article shows three gating patterns: scope checks, role checks, and email-domain checks. All three depend on the same principle, which is that the server enforces access only after the token has been verified and the claims have been parsed. Scope is the cleanest fit for least-privilege access, roles work for broader admin-like control, and email claims are useful for internal boundaries. The technical risk is when teams confuse claim presence with governance, because the claim is only as trustworthy as the authorization server behind it.

Practical implication: define which claims are authoritative for each tool before implementation, and reject any handler logic that depends on implied trust.

Client registration, discovery, and token caching shape operational risk

The build pattern includes dynamic client registration, OIDC discovery, and local token caching during development. Those features reduce manual work, but they also create failure modes if teams do not understand how cache state and audience checks interact with policy. A stale token can make permissions appear broken, while a mismatched audience can silently undermine otherwise correct enforcement. In practice, the operational boundary is not just token verification but lifecycle handling of clients, refresh behaviour, and environment configuration.

Practical implication: test permission changes with fresh tokens, validate audience settings per environment, and manage MCP clients as governed identities.

NHI Mgmt Group analysis

MCP auth is becoming an identity governance problem, not a developer convenience feature. The article is really about where tool invocation authority lives. Once an AI assistant can call third-party services through an MCP server, the security model depends on whether identity claims, scopes, and client registration are governed centrally or improvised inside each app. The implication is that MCP belongs in the same governance conversation as NHI and application access, not as a sidecar feature.

Claim-based enforcement only works when the authorization boundary is explicit. The server verifies JWTs locally, but the authority to issue scopes still sits in the auth layer. That division is healthy only if teams understand which side owns issuance, which side owns enforcement, and which claims are acceptable for each tool. The practitioner conclusion is that tool access must be designed as a policy chain, not a one-off code check.

Access review logic gets weaker when the identity behind the request is abstracted away. MCP makes it easy to focus on the assistant interaction and forget the human or service identity behind the invocation. When requests are scoped through OAuth, the real governance task is preserving traceability from tool action back to the authenticated subject. Practitioners should treat auditability as a first-class design requirement, not a post-deployment logging exercise.

Token lifecycle discipline matters more than the demo path suggests. The walkthrough’s cache and discovery notes show how quickly permission behaviour can drift between development and production. That is a classic identity lifecycle problem: discovery metadata, client state, and token freshness all affect whether access remains aligned with policy. The lesson for IAM and NHI teams is that runtime control is only as strong as the lifecycle hygiene around it.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That gap makes Ultimate Guide to NHIs the next step for teams deciding how to govern delegated access across humans, service accounts, and AI-driven tool use.

What this signals

Claim-based MCP access will become a standard NHI governance pattern as AI integrations scale. The practical challenge is not whether OAuth exists, but whether teams can keep scopes, roles, and client identities aligned as tools multiply across environments. With 98% of companies planning to deploy more AI agents within 12 months, the governance model has to assume rapid expansion, not stable pilot conditions.

The next failure mode will be policy drift between development caches, discovery metadata, and production audience settings. That is where identity assurance breaks down first, especially when teams reuse the same token and client patterns across local testing and live operations.

For practitioners, the important shift is to manage MCP clients as governed identities and not as disposable integration details. That means integrating lifecycle controls, audit requirements, and scoped permissions into the same oversight model used for NHI and privileged access.

For practitioners

• Define the MCP authorization boundary Separate token issuance from tool enforcement before you write the first handler. Make the authorization server own scopes and claims, and make the MCP server verify tokens and enforce policy locally.
• Bind every tool to explicit claims Require each tool to check a specific scope, role, or trusted internal attribute rather than relying on general login state. Keep the claim requirements documented next to the tool definition so reviewers can trace intent to enforcement.
• Treat client registration as governed identity Register MCP clients as managed entities with explicit audience, discovery, and lifecycle rules. Review how client onboarding, revocation, and environment-specific config are handled before broadening access.
• Test with fresh tokens after every permission change Clear cached tokens before validating new scopes or role mappings, especially in local development. Confirm that the token audience, discovery document, and claims all match the environment you are testing.

Key takeaways

• MCP security is an identity problem first and a coding problem second.
• JWT claims, client registration, and token lifecycle together determine whether tool access is actually governed.
• Teams that separate issuance from enforcement will have a more auditable and scalable MCP access model.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Openid Connect discovery: OpenID Connect discovery is the metadata document that tells clients where to find identity endpoints such as jwks_uri. It removes hardcoded configuration from clients, but it also makes discovery integrity part of the trust chain, so teams should always fetch and validate it over HTTPS.
• Json Web Token: A JSON Web Token is a compact, signed token that carries claims between systems so they can verify identity or authorization without consulting a central session store. In practice, its safety depends on strict validation of the signature, issuer, audience, expiry, and algorithm before any trust decision is made.
• Client registration: Client registration is the process of creating and configuring an application or agent identity so it can request tokens and access resources. In MCP environments, registration settings often vary by tenant, which makes registration a governance control as much as an onboarding task.

What's in the full article

Descope's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step Next.js project scaffolding for an auth-aware MCP server.
• Copy-paste token verification and JWKS discovery code for production and local testing.
• Descope console configuration for MCP Server Resources, scopes, and policies.
• Local Claude Desktop testing flow using mcp-remote and OAuth caching behaviour.

👉 Descope's full post covers the setup steps, token checks, and development gotchas in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.