Identity-Bound MCP Authorization Per-server foundation · Gateway optimization
Architecture research · July 21, 2026

Secure every server. Optimize through a gateway.

The new MCP Enterprise-Managed Authorization profile enables identity-bound access directly at each MCP server. A gateway should arrive later as a scale, governance, and usability optimization—not as the original security boundary.

01 · Decision

Authorization per server is the foundation. The gateway is the optimization.

The architecture should mature from independently secure MCP resources to a shared authorization control plane, then to a transparent and eventually aggregating gateway.

Recommendation

Preserve server authority at every maturity stage

Each production MCP server remains an identifiable OAuth resource with an exact audience, server-specific RBAC, tool-level authorization, and a domain audit trail—even when normal clients connect through a gateway.

Specification fact

Enterprise SSO can authorize individual servers

The enterprise IdP issues a resource-specific ID-JAG. The MCP server’s Resource Authorization Server exchanges it for an access token targeted to that MCP server.

Architecture analysis

Gateway-first creates unnecessary coupling

Requiring a gateway before identity-bound authorization delays secure server delivery and risks turning the gateway into an over-privileged monolith.

1 Secure server

Exact resource, audience, roles, scopes, and domain policy.

2 Share auth components

Common IdP federation, token service, SDK, and policy runtime.

3 Transparent gateway

Central ingress and observability while server tokens remain unchanged.

4 Aggregate catalogs

One client connection with namespaced, policy-filtered tools.

5 Optimize operations

Central routing, metering, policy administration, and lifecycle control.

02 · Authorization model

One enterprise identity. Multiple protected MCP resources.

“Auth per server” should not mean multiple login systems. It means shared identity infrastructure with distinct resource identifiers, audiences, permission models, and enforcement boundaries.

Two valid connection paths Direct server authorization and gateway-optimized authorization coexist
Direct and gateway MCP authorization paths An enterprise user signs into an MCP client through a shared identity provider. The client can obtain a server-specific ID-JAG and connect directly, or obtain a gateway token and let the gateway exchange for server-specific internal tokens. MCP Client VS Code / Agent host Enterprise IdP Entra or identity broker SSO Server Auth Service Resource-specific policy MCP Server Exact audience ID-JAG access token DIRECT PATH Gateway Auth Trust-domain admission MCP Gateway Catalog, routing, policy MCP Server Server token required GATEWAY PATH gateway token server token shared enterprise identity
Swipe horizontally to inspect the full architecture.
Dimension Direct per-server authorization Gateway-optimized authorization
External resource Each MCP server Gateway or trust-domain virtual MCP server
Client configuration One connection per server One curated connection per trust domain
Final server token Server-specific Server-specific internal token
Server RBAC Required Still required
Catalog Distributed Aggregated and policy-filtered
Primary value Security independence and portability Scale, usability, governance, and operations
Failure domain Localized to a server Gateway becomes a critical shared dependency

03 · Direct per-server path

The new profile supports identity-bound access without a gateway.

The client authenticates once to the enterprise IdP, obtains a resource-specific ID-JAG, exchanges it at the MCP server’s authorization service, and receives a token whose audience is the individual MCP server.

Each server owns a resource identity

urn:organization:mcp:observability

The token audience must match this exact protected resource.

Authorization service can be shared

One deployed authorization platform can host logically isolated policies for many MCP resources.

Policy stays domain-specific

Scopes and roles differ for engineering, content, observability, deployment, and rights-sensitive domains.

Direct access remains independently safe

A client cannot bypass controls by reaching the server outside the gateway path.

Required server surface

Server element Required setup Why it matters
Resource URI Stable identifier unique to the MCP server or trust resource Creates an explicit authorization boundary.
Protected Resource Metadata /.well-known/oauth-protected-resource and authorization-server references Allows MCP clients to discover the correct issuer and flow.
Authorization metadata Advertise enterprise-managed grant support and token endpoints Enables compatible clients to select the ID-JAG path.
Audience validation Reject tokens whose aud does not identify this server Prevents token substitution and cross-server reuse.
RBAC manifest Map identity roles to scopes and scopes to tool permissions Converts enterprise identity into server capabilities.
Argument policy Evaluate environment, object, rights, risk, and request context RBAC alone cannot express fine-grained domain rules.
Audit event Record subject, client, agent, tool, resource, decision, and result Preserves complete identity and execution lineage.
Illustrative Protected Resource Metadata 
{
  "resource": "urn:nba:mcp:observability",
  "authorization_servers": [
    "https://mcp-auth.internal.example.com"
  ],
  "scopes_supported": [
    "logs.read",
    "metrics.read",
    "incidents.read",
    "incidents.update"
  ]
}

04 · Identity-bound RBAC

Authorize the relationship, not only the user.

A robust decision binds the enterprise subject to the client, agent actor, protected server, capability, arguments, and runtime context.

Authorization tuple

tenant × subject × client × actor × server × scope × tool × arguments × context

User-only RBAC is insufficient for agentic access. The same human may receive different authority through an approved enterprise IDE, an autonomous agent, or an unknown client.

Layered permission model

1 Enterprise identity

Stable tenant and subject identifiers from Entra or the identity broker.

2 Enterprise role

App role, managed group assignment, workload identity, or policy attribute.

3 Server entitlement

Permission to access a specific MCP resource through an approved client.

4 Tool capability

Scope and explicit permission for the selected tool class.

5 Domain policy

Argument, object, environment, rights, risk, and state evaluation.

Illustrative normalized principal

{
  "tenantId": "entra-tenant-guid",
  "subjectId": "entra-object-guid",
  "clientId": "vscode-enterprise-mcp",
  "actorId": "agent:incident-triage",
  "roles": ["production-support"],
  "scopes": ["logs.read", "incidents.read"],
  "authenticationContext": {
    "mfa": true,
    "managedDevice": true
  }
}

Control: preserve the human subject and the agent actor as separate principals. Do not collapse both into one sub claim.

Illustrative per-server RBAC manifest 
resource:
  id: urn:nba:mcp:observability

roles:
  observability-reader:
    scopes: [logs.read, metrics.read, incidents.read]

  incident-responder:
    inherits: [observability-reader]
    scopes: [incidents.update, diagnostics.execute]

tools:
  observability.search_logs:
    requiredScopes: [logs.read]
    risk: read
    policy: log-query-policy

  observability.run_diagnostic:
    requiredScopes: [diagnostics.execute]
    risk: execute
    policy: diagnostic-policy

05 · Shared authorization platform

Centralize the control plane before centralizing the traffic plane.

The enterprise can standardize identity federation, token issuance, policy evaluation, and auditing while MCP clients still connect directly to individual servers.

Shared implementation

  • Entra federation and identity normalization
  • ID-JAG validation and JWT signing
  • Authorization metadata and client registration
  • Policy decision runtime
  • Signing-key rotation and token revocation
  • Normalized audit schema

Server-owned configuration

  • Resource identifier and audience
  • Permitted clients and agents
  • Roles, scopes, and tool permissions
  • Argument and resource policies
  • Risk and data classifications
  • Downstream credentials and domain audit

Architecture boundary: one authorization service deployment can support many MCP servers, but every token remains resource-specific and every policy namespace remains independently governed.

Reusable server security package

A common package such as @nba/mcp-identity should remove repetitive security code without removing domain decisions.

Token verificationIssuer, audience, expiry, client, actor, and replay controls.
Principal normalizationStable Entra identifiers and workload/client identity separation.
Policy adapterConsistent request model for role, tool, argument, and context evaluation.
Audit contractDecision, policy version, invocation ID, result, and downstream lineage.

06 · Gateway optimization

Add the gateway to reduce complexity—not to compensate for insecure servers.

A gateway can begin as transparent ingress. It can later become an aggregating MCP server with one enterprise connection, a curated tool catalog, and internal resource-token exchange.

Gateway stage What changes What does not change Primary benefit
Transparent ingress TLS, WAF, routing, rate limits, common telemetry Client still obtains server-specific tokens Low-risk operational consistency
Policy-aware proxy Trust-domain admission and global deny controls Server performs fine-grained authorization Central governance without catalog aggregation
Aggregating gateway One MCP connection, unified catalog, internal token exchange Every server still requires its own audience-bound token Client simplicity and platform scale

Nested authorization

Gateway decision

Admission and capability class

Can this subject, client, and agent enter the trust domain and invoke this general category of capability?

Server decision

Exact domain operation

Can this principal execute this precise tool with these arguments against this resource in its current state?

Gateway-to-server token boundary

{
  "iss": "https://mcp-internal-auth.example.com",
  "aud": "urn:nba:mcp:observability",
  "sub": "entra:tenant-guid:user-guid",
  "azp": "mcp-operations-gateway",
  "client_id": "vscode-enterprise-mcp",
  "act": {
    "sub": "agent:incident-triage"
  },
  "permissions": ["observability.search_logs"],
  "invocation_id": "inv-4d746",
  "exp": 1784685660
}

Release blocker: never forward the client’s gateway token unchanged to an individual MCP server. Mint or exchange for a short-lived token with the exact server audience.

07 · Migration sequence

Move from secure independence to governed aggregation.

The sequence preserves reversibility. A gateway can be introduced, expanded, or bypassed without weakening the underlying MCP servers.

Phase 1

Identity-bound server foundation

Implement direct enterprise-managed authorization for two or three read-heavy MCP servers.

  • Documentation and knowledge
  • Observability
  • GitHub or engineering
Phase 2

Common authorization SDK

Standardize token verification, principal normalization, policy calls, and audit output.

Phase 3

Transparent gateway

Add network ingress, common controls, routing, and observability while keeping server-specific client tokens.

Phase 4

Aggregating gateway

Introduce one connection, catalog federation, policy filtering, session multiplexing, and internal token exchange.

Migration invariants

Direct security survivesEvery server remains safe without the gateway.
Audiences never widenAggregation does not create a universal bearer token.
Domain ownership remains localServer teams own tool schemas and business authorization.
Client migration is gradualDirect and gateway paths may coexist during adoption.

08 · Security controls

Treat identity propagation as a constrained security protocol.

The design must resist token substitution, confused-deputy behavior, identity collapse, replay, policy drift, and privilege expansion.

Risk Per-server control Gateway control
Token substitution Validate exact issuer, audience, resource, client, and expiry Mint exact audience-bound internal tokens
Confused deputy Authorize subject × client × actor × tool Preserve original principal and approved gateway identity
Replay Short token lifetime and jti replay protection for sensitive grants Invocation-bound tokens and centralized deny controls
Privilege expansion Tool and argument policy cannot exceed token permissions Gateway projection may only reduce capabilities
Agent impersonation Keep user subject and agent actor distinct Preserve both identities through token exchange
Policy drift Versioned server policy and contract tests Central policy registry and rollout controls
Bypass Direct endpoint remains independently protected Network policy may make gateway preferred, never implicitly trusted
Release-blocking server checks
  • Reject direct Entra tokens that were not issued for the MCP resource.
  • Reject gateway tokens targeted to another server.
  • Reject missing or unapproved client identity.
  • Reject an agent actor when the selected tool prohibits delegated agents.
  • Never expose downstream credentials in tool output or logs.
  • Never authorize a request solely because it originated from a gateway network.

09 · Implementation blueprint

Build the smallest complete slice first.

The initial implementation should prove direct identity-bound authorization, reusable server integration, and auditable policy decisions before catalog aggregation.

Initial reference slice

Component Initial responsibility Success criterion
Entra / identity broker Authenticate user and issue or facilitate enterprise identity assertions Stable user, client, tenant, and authentication-context claims
MCP authorization service Validate ID-JAG, map roles, issue resource-specific token Unauthorized client–user–resource combinations receive no token
@nba/mcp-identity Verify tokens, normalize principal, call policy, emit audit Two servers integrate without custom security forks
Observability MCP Read-only log and metric tools with field and time-range controls Argument-level denial and redaction are independently enforced
Documentation MCP Rights-aware or entitlement-aware knowledge retrieval Identity and content restrictions remain traceable
Audit pipeline Correlate identity, decision, invocation, result, and policy version One query reconstructs the end-to-end authorization lineage

Decision gates

Identity integrityCan the platform preserve user, client, and agent identities independently?
Resource isolationDoes a token for one MCP server fail at every other server?
Policy consistencyDo SDK integrations produce identical decision and audit contracts?
Gateway readinessCan the future gateway request restricted server tokens without bypassing policy?

Architecture success condition: adding the gateway changes client experience and platform operations, but does not require rewriting the authorization model of existing servers.

10 · Evidence and provenance

Source-grounded claims with explicit architectural inference.

Specification requirements are separated from architectural recommendations. The gateway progression is an enterprise design derived from the protocol’s resource-server model.

Specification-grounded

Direct per-server authorization

MCP defines the MCP server as the OAuth resource server, with its authorization server discoverable through Protected Resource Metadata. Enterprise-Managed Authorization exchanges an ID-JAG for a token at that server’s Resource Authorization Server.

Architectural inference

Gateway as later optimization

Because each server can be independently protected, the gateway can be introduced after server authorization to aggregate catalogs, centralize operations, and reduce client complexity while retaining exact server audiences.

Primary source registry
  1. S1
    MCP Enterprise-Managed Authorization overview

    Defines centralized enterprise policy, SSO behavior, client/server responsibilities, ID-JAG handling, and authorization-server validation.

  2. S2
    Stable Enterprise-Managed Authorization specification

    Normative profile defining the MCP client, MCP resource server, Resource Authorization Server, enterprise IdP, and identity assertion exchange.

  3. S3
    MCP core authorization specification

    Defines the MCP server as an OAuth resource server and requires RFC 9728 Protected Resource Metadata and authorization-server discovery.

  4. S4
    MCP security best practices

    Documents confused-deputy risks, token safety, scope minimization, session security, and proxy-specific authorization concerns.

  5. S5
    TrueFoundry Azure Entra OAuth MCP guide

    Concrete per-server Entra OAuth setup and gateway integration example using authorization-code and client-credentials flows.

  6. S6
    TrueFoundry MCP Gateway overview

    Describes centralized registry, inbound/outbound authentication, virtual MCP servers, guardrails, and tool-level metrics.

Methodology, assumptions, and limitations
  • Method: compare the stable enterprise-managed extension, MCP core authorization model, MCP security guidance, and a current Entra gateway implementation example.
  • Assumption: the organization will use Microsoft Entra as the upstream enterprise identity authority, possibly through an internal compatibility broker.
  • Inference: gateway stages and trust-domain topology are architecture recommendations, not protocol-mandated MCP roles.
  • Limitation: native Entra issuance of MCP ID-JAG assertions must be validated against current Microsoft implementation support before production commitment.
  • Version date: July 21, 2026. Protocol drafts and client support can change.