Federated Authentication

Char doesn’t manage user accounts. It doesn’t store passwords. It doesn’t have a user database to breach. Instead, Char trusts your existing identity provider—the system that already knows who your users are. This approach is called federated authentication: rather than each application maintaining its own identity system, applications trust assertions from a central identity provider. When a user authenticates to your IDP, they receive a cryptographically signed token that proves their identity. Char validates that token rather than asking users to create another account.

​

Federated Authentication vs SSO

These terms are often confused, but they describe different things: Single Sign-On (SSO) means signing in once and accessing multiple applications without re-authenticating. When you log into Google and then access Gmail, Drive, and Calendar without additional login prompts, that’s SSO. The “single” refers to the user’s experience—one login for multiple apps. Federated authentication means trusting identity assertions from an external provider. Your IDP says “this is Alice from Acme Corp” and Char believes it. The “federation” refers to the trust relationship between systems. Char uses federated authentication. Whether your users experience SSO depends on your IDP configuration—if they’re already logged into Okta when they visit an application with Char embedded, they won’t see a login prompt. But Char itself doesn’t implement SSO; it trusts tokens your IDP has already issued. The distinction matters because it clarifies responsibilities. Your IDP handles the authentication experience—login flows, MFA challenges, session management. Char handles authorization within its domain—what tools users can access, what conversations they own.

​

How Token Validation Works

When a user interacts with the Char agent, your application passes their JWT token—the same token they used to authenticate to your application. Char validates this token against your IDP’s public keys. The validation is cryptographic. Your IDP signs tokens with its private key. Char verifies signatures using the corresponding public key, published through the JWKS (JSON Web Key Set) endpoint. If the signature is valid, the token came from your IDP. If it’s invalid, the request is rejected. This asymmetric approach has an important property: Char doesn’t need any secrets from your IDP. The public key is exactly that—public. Anyone can use it to verify signatures, but only your IDP can create them.

​

Why This Design

The federated model eliminates several categories of risk: Credential theft. Char has no credential database. There’s nothing to steal. Even if Char’s servers were compromised, attackers couldn’t obtain user passwords because we never had them. Shared secret exposure. Traditional integrations require sharing a client secret between services. If either service is breached, the secret is compromised. Char’s public key validation has no shared secret—the “secret” (private key) never leaves your IDP. Shadow access. When someone leaves your organization, you disable them in your IDP. That’s it. Char access is immediately revoked because the user can no longer obtain valid tokens. There’s no separate system to update, no orphaned accounts to discover later. Password policy fragmentation. Char doesn’t enforce password policies because Char doesn’t manage passwords. Your IDP enforces whatever policies your organization requires—MFA, password complexity, rotation schedules. Char inherits these protections automatically.

​

The Token Lifecycle

Tokens are ephemeral. When Char receives a token, the validation process is:

1. Fetch your IDP’s current public keys (cached, refreshed periodically)
2. Verify the token’s cryptographic signature
3. Check that the issuer (iss claim) matches your configured IDP
4. Check that the audience (aud claim) includes your application
5. Check that the token hasn’t expired (exp claim)
6. Extract the user’s identity from the subject (sub claim)
7. Discard the token

There’s no token database. Tokens aren’t stored, cached long-term, or persisted anywhere that could be breached. Each request validates its token independently. This statelessness has consequences. If your IDP rotates its signing keys, old tokens immediately become invalid—even if they haven’t expired. If you revoke a user’s access in your IDP, they can’t obtain new tokens. Their existing session continues only until their current token expires (typically minutes to hours, depending on your IDP configuration).

​

Audience Validation

When your IDP serves multiple applications, audience validation prevents token confusion attacks. Consider an organization using Okta for both an internal HR portal and a customer-facing application. A token issued for the HR portal shouldn’t grant access to the customer application, even though both use the same IDP. Char enforces this through audience validation. When you configure your organization, you specify your application’s client ID. Every token must include this client ID in its audience claim. Tokens intended for other applications—even from the same IDP—are rejected.

​

Multi-Tenant IDPs

Enterprise identity providers often serve multiple tenants. Azure AD (Entra) serves many organizations through a single infrastructure. Google Workspace distinguishes organizations by domain. Char validates tenant claims to prevent cross-tenant token misuse. A token from one Okta organization can’t be used to access another organization’s Char deployment, even if both organizations use Okta. The specific claim varies by IDP—tid for Azure AD, hd for Google Workspace, organization claims for Okta. Char understands these variations and validates appropriately.

​

The Tradeoffs

The federated model has genuine tradeoffs: IDP dependency. If your IDP is down, users can’t authenticate to Char. There’s no fallback mechanism, no local accounts, no emergency access. Your IDP’s availability is Char’s availability. Token lifetime constraints. Char can’t extend token lifetimes. If your IDP issues tokens that expire in 5 minutes, users will need to re-authenticate frequently. Your IDP’s token policies apply to Char interactions. Claim requirements. Char needs certain claims to function—subject, issuer, audience, expiration. If your IDP doesn’t include these (unusual but possible with custom configurations), integration won’t work. These tradeoffs are intentional. The alternative—maintaining our own credential database, supporting local accounts, extending token lifetimes—would reintroduce exactly the risks the federated model eliminates.

​

Identity Delegation to Remote Services

The federated model extends beyond user authentication. When the Tool Hub invokes tools on Remote MCP servers, it uses the same IDP to obtain appropriately-scoped tokens—a pattern called ID-JAG (Identity Assertion Authorization Grant). The insight is that your enterprise IDP is already the source of truth for identity across your internal services. Rather than managing separate credentials for each MCP server, the Hub exchanges the user’s identity for service-specific tokens through your IDP. This has several consequences: No credential storage for remote services. The Hub never holds long-lived credentials for MCP servers. Each token exchange produces a short-lived, audience-scoped token. When the user’s session ends, tokens simply expire—no cleanup required. Identity fidelity. When Alice invokes a tool, the MCP server’s audit log shows Alice, not a service account. Permission checks use Alice’s actual roles and groups. The user’s identity flows through the entire chain. Centralized revocation. Disable a user in your IDP and they immediately lose access to all MCP servers. The next token exchange fails. There’s no need to revoke access in each service individually. Audience isolation. Each token is scoped to a specific MCP server. A token for your data platform cannot be used to call your ticketing system, even though both trust the same IDP. This prevents confused deputy attacks. For technical details of the token exchange flow, see the Remote MCP Authentication reference.

​

What Your IDP Already Handles

By delegating to your IDP, Char inherits capabilities that would otherwise require significant implementation: Char doesn’t need to implement any of this because your IDP already does.

​

Further Reading