Notifications
Clear all
Topic starter
19/08/2026 3:27 pm
TL;DR: MCP tool development is easy, but proving who can call those tools is the hard part, and Descope’s walkthrough shows why OAuth issuance, discovery, and claim-based enforcement have become the real control plane for auth-aware AI integrations. The lesson is that MCP security is not just about tools, it is about binding every request to a governed identity and permission model.
NHIMG editorial — based on content published by Descope: How to Build an Auth-Ready MCP Server With Next.js and Descope
Questions worth separating out
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.
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.
Q: What breaks when MCP tool access is not default-deny?
A: Tool discovery and invocation become open-ended privilege expansion paths.
Practitioner guidance
- Define the MCP authorization boundary Separate token issuance from tool enforcement before you write the first handler.
- 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.
- Treat client registration as governed identity Register MCP clients as managed entities with explicit audience, discovery, and lifecycle rules.
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.
👉 Read Descope's guide to building an auth-ready MCP server with Next.js →
MCP auth in practice: what IAM teams need to control?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
19/08/2026 4:11 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Auth-ready MCP servers expose the real identity control gap
