Enterprise SSO for MCP

Your enterprise already has SSO. Your users authenticate once and access all their applications. Why should AI agents be different? With Char, they’re not. The same identity that logs users into your applications grants them access to AI-powered tools—including your internal MCP servers. No service accounts for users. No per-service OAuth consent flows. Just your existing enterprise identity extended to AI tooling.

​

The User Experience

A user signs into your application through your enterprise IDP—the same login they use every day. That’s the only authentication they see. When they ask the AI agent to query an internal database or update a ticket in your internal system, it just works. No OAuth popups. No consent screens. No “click here to connect your account” flows. This happens because the token exchange that grants access to internal MCP servers is entirely server-to-server. The user already proved who they are when they signed in. The Tool Hub exchanges that proof with your IDP behind the scenes, and your MCP servers accept it because they trust the same IDP. The user’s browser is never redirected. No additional credentials are requested.

​

The Problem with AI Agent Auth

Most AI agent platforms that access enterprise services fall into two categories: Service accounts. The agent uses elevated credentials to access APIs. Problems: over-privileged, no user-level audit trail, credentials to manage, blast radius is everything the service account can access. Per-service OAuth. Each service connection requires the user to complete an OAuth consent flow. Problems: UX friction, token management complexity, doesn’t work for real-time agent workflows that span multiple services. Neither approach extends your existing SSO. You’ve invested in enterprise identity—Okta, Azure AD, Auth0—but your AI agents can’t use it.

​

How Char Solves This

Char uses your existing IDP for everything. When a user’s AI agent needs to call an internal MCP server: The key insight: your MCP server validates against the same IDP it already trusts for SSO. Char doesn’t issue identity tokens—it exchanges yours through your IDP.

​

Why This Is Different

​

Industry Standards

This architecture implements emerging standards: XAA was added to the MCP specification in November 2025 as the standard for enterprise-governed AI agent access. Char implements this flow today.

​

IDP Requirements

Your IDP needs to support RFC 8693 (Token Exchange) to issue ID-JAGs: If your IDP doesn’t support RFC 8693 token exchange, internal MCP servers using ID-JAG won’t work. External MCP servers (third-party services) use standard OAuth with PKCE instead.

​

What MCP Servers Require

For this architecture to work, internal MCP servers must be able to validate tokens from your IDP—the same validation they likely already perform for SSO. They also need to accept JWT Bearer Grants (RFC 7523), which is how the Tool Hub presents ID-JAGs in exchange for access tokens. The key insight is that most of this infrastructure already exists. If your MCP server already trusts your IDP for user authentication, it can trust ID-JAGs from that same IDP with minimal additional work. See the Remote MCP Authentication reference for implementation details.

​

Setup Requirements

Remote MCP with ID-JAG requires a one-time setup by your IDP admin. This is different from basic SSO authentication, which only requires configuring your IDP details in the Char dashboard.

​

What’s different about Remote MCP

​

Why Char needs to be registered

For basic SSO, Char only validates tokens using your IDP’s public JWKS endpoint—no registration needed. For Remote MCP, the Tool Hub must authenticate as a client to your IDP to perform token exchange. Your IDP won’t process token exchange requests from an unknown client. This is a security feature: your IDP controls which applications can request tokens on behalf of your users.

​

One-time IDP setup

Your IDP admin needs to:

​

Why this architecture

Once setup is complete, the ongoing experience is seamless. Consider an enterprise using Okta with XAA enabled:

• Users authenticate to applications via Okta
• Internal MCP servers trust Okta for SSO
• Char validates user tokens against Okta’s JWKS
• The Tool Hub exchanges tokens via Okta (using its registered credentials)
• MCP servers validate ID-JAGs against Okta

Every component trusts the same identity provider. After the one-time Char registration, new MCP servers can be added without additional credential setup—they just need to trust your IDP. This is the architectural payoff of federated identity.

​

Admin Governance Replaces User Consent

Traditional OAuth requires users to approve each application connection. This made sense when users were connecting personal accounts to third-party apps—you want the user to decide whether to share their Google Calendar with a scheduling tool. Enterprise app-to-app access is different. The decision about whether your internal CRM can access your internal ticketing system isn’t a user decision—it’s an organizational policy. XAA reflects this by moving the approval from per-user consent flows to admin-configured policies in the IDP. When an admin enables XAA between applications in Okta, they’re saying: “Users of Application A are allowed to access Application B’s resources through their existing identity.” The IDP enforces this policy during token exchange. If the policy permits it, the exchange succeeds. If not, it fails. The user never sees a consent screen because the organization already made that decision. This is why there are no OAuth popups when accessing internal MCP servers. The enterprise admin configured the access policy. The IDP enforces it. The user just works.

​

Security Properties

​

Further Reading