Cross-App Access: Why Enterprise MCP Needs IdP-Mediated Authorization

The Shadow IT Problem in Agent Authorization

When an MCP client connects to an MCP server today, it establishes a direct OAuth connection. The agent asks the user for consent, the user approves, and a token is issued. This works — but enterprise IT has zero visibility into what just happened.

Every agent-to-tool connection is a bilateral trust relationship between the MCP client and the MCP server. InfoSec can't see it, can't audit it, and can't revoke it from a central place. Each connection is effectively shadow IT. In a world where a single developer might have dozens of agents connecting to dozens of tools, this creates a sprawling web of ungoverned access that no compliance framework can accept.

What is Cross-App Access?

Cross-App Access (XAA) — the market name coined by Okta for the Identity Assertion JWT Authorization Grant (ID-JAG) — is an OAuth 2.0 extension being standardized through the IETF OAuth Working Group. It inserts the enterprise Identity Provider into the authorization flow as the central policy decision-maker.

Instead of apps establishing bilateral trust with each other, every agent-to-tool connection goes through the enterprise IdP. The IdP decides whether the connection is allowed, what scopes are granted, and logs the decision. The user never sees a consent screen — the enterprise policy replaces it.

The MCP specification formalized this as SEP-990: Enterprise-Managed Authorization in the November 2025 update, making it a first-class extension of the MCP auth model.

The Three-Party Token Exchange

XAA involves three parties: the MCP Client (requesting app), the Enterprise IdP (policy authority), and the MCP Server (resource app via AuthPlane).

1. User authenticates via SSO. The user logs into the MCP client through their corporate identity provider — standard OIDC. They get an ID token.
2. MCP client requests an ID-JAG. The client sends a Token Exchange request (RFC 8693) to the IdP's token endpoint. It asks for an assertion JWT targeted at the specific MCP server it wants to access.
3. IdP evaluates policy. The IdP checks enterprise policy: Is this app-to-app connection allowed? What scopes? Does the user's group membership qualify? Is step-up auth required?
4. IdP issues the ID-JAG. If policy passes, the IdP returns a signed JWT — the ID-JAG assertion. It's audience-bound to the downstream MCP server, contains the approved scopes, and expires in under 5 minutes.
5. MCP client presents ID-JAG to AuthPlane. Using the JWT Bearer grant type (grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer), the client presents the assertion to AuthPlane.
6. AuthPlane validates and issues an access token. AuthPlane verifies the JWT signature against the IdP's JWKS endpoint, checks audience binding, validates the JTI for single-use, evaluates its own policy engine, and issues a short-lived access token.

The entire exchange happens without user interaction after the initial SSO login. No consent screen. No redirect. No popup.

Why Not Standard OAuth?

Standard OAuth creates direct trust between client and server. The user authorizes the connection, and the client gets a token. This is fine for consumer apps where the user is the authority. But in enterprise, the organization is the authority — not the individual user.

With XAA, IT/InfoSec can:

• Pre-approve or deny connections — before any user can authorize them
• Enforce scope restrictions — the IdP decides what scopes are allowed, not the user
• Require step-up auth — high-privilege connections can demand MFA
• Revoke access instantly — from a single point, for all users, for a specific app pair
• Audit everything — every connection decision is logged at the IdP

Security Invariants

AuthPlane enforces strict security invariants on every ID-JAG assertion it processes:

• Algorithm restrictions: alg:none and all HMAC algorithms (HS256, HS384, HS512) are rejected. Only asymmetric algorithms (ES256, RS256) are accepted.
• Single-use assertions: Every JTI is consumed atomically. Replay is impossible.
• Short-lived: Maximum assertion lifetime of 5 minutes (configurable down, never up).
• Audience binding: The assertion's aud claim MUST match AuthPlane's issuer URL.
• Client binding: The client_id in the assertion MUST match the authenticated client.
• No refresh tokens: JWT Bearer grants never produce refresh tokens. Every access token requires a fresh assertion from the IdP.
• SSRF protections: JWKS fetch URLs are validated against an allowlist. No internal network access.
• Policy evaluation: Every assertion passes through the policy engine before token issuance.

How AuthPlane Implements XAA

AuthPlane's XAA implementation is built on four components:

Trusted IdP Registry

Administrators register enterprise IdPs with their issuer URL and JWKS endpoint. AuthPlane discovers and caches the IdP's signing keys with automatic rotation. Only registered IdPs can issue assertions that AuthPlane will accept.

JWT Bearer Grant Type (RFC 7523)

AuthPlane's token endpoint accepts grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer. It validates the assertion signature, checks all security invariants, and maps the assertion claims to an access token.

Policy Engine

Before issuing a token, AuthPlane evaluates configurable policy rules: subject mapping (how IdP users map to AuthPlane principals), scope restrictions (what scopes are allowed for this IdP/client pair), and group-based access control.

Audit Trail

Every assertion validation — successful or rejected — is logged with the full context: IdP issuer, subject, client, requested scopes, policy decision, and resulting token (if issued). This gives compliance teams a complete audit trail of every enterprise-mediated agent connection.

What This Means for Regulated Industries

SOC 2, HIPAA, and FedRAMP all require centralized access governance. XAA transforms agent authorization from an ungovernable sprawl of bilateral OAuth connections into a centrally managed, auditable, and revocable system. The enterprise IdP — the same system that already governs employee access to every other application — now governs agent access too.

For compliance teams, this means:

• Every agent-to-tool connection is visible in the IdP's access log
• Access reviews cover agent connections alongside human access
• Offboarding a user or decommissioning an agent revokes all their connections from one place
• Scope restrictions are enforced by policy, not by trusting individual users to grant appropriate permissions

XAA is available now in AuthPlane. See the quickstart guide to deploy, or check the source on GitHub.