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.

​

How Char Fits Your Trust Model

A reasonable question: if tokens are issued for your application, why does Char accept them? Char operates as a delegated validator within your application’s trust boundary. When you embed Char in your application and configure your client ID, you’re telling Char: “validate tokens on my behalf, for my users.” This pattern is common in modern architectures:

• API gateways validate tokens for backend microservices
• Embedded analytics SDKs verify user identity for personalization
• Backend-for-frontend (BFF) layers handle auth on behalf of SPAs

Char never uses your token to access other services or act as the user elsewhere. It validates the token to establish who the user is, extracts the identity claims, then discards the token. The token’s audience is your application—and Char is part of your application’s infrastructure. From your IDP’s perspective, the trust relationship is with your application. You control which origins can embed Char, and you configure which client ID Char should expect. Char is an implementation detail of how your application handles identity-scoped AI interactions.

​

Auth Platforms vs Direct Identity Providers

Not all identity providers are the same. There’s an important distinction between direct identity providers and auth platforms. Direct identity providers are the source of truth for user identities. Users are provisioned directly in these systems:

• Google Workspace — users exist in Google
• Microsoft Entra ID (Azure AD) — users exist in Microsoft
• Okta (when used as primary IDP) — users exist in Okta

Auth platforms are intermediaries that handle authentication flows but delegate to upstream providers. They don’t store passwords for social logins—they orchestrate OAuth/SAML flows with other providers:

• Auth0, WorkOS, Clerk, Scalekit
• Better Auth, Logto, Keycloak
• Firebase Auth, AWS Cognito

When you use an auth platform with social login or enterprise SSO, there’s a layered flow: The key insight: Char validates the auth platform’s tokens, not the upstream provider’s tokens. When a user signs into Auth0 via Google, Auth0 receives Google’s token, extracts user information, then issues its own Auth0 token. That Auth0 token is what your application receives and what Char validates. The Google token never reaches Char. This layering has practical implications: Token claims reflect the platform, not the upstream provider. The iss claim will be https://acme.auth0.com/, not https://accounts.google.com. The sub claim will be Auth0’s user ID, not Google’s. The platform is your IDP from Char’s perspective. Configure Char with Auth0’s domain/client ID, not Google’s. Char doesn’t know or care that Google was involved. User identity is managed by the platform. If a user signs in with Google today and Microsoft tomorrow (both configured in your Auth0), Auth0 can link these identities. The user has one identity in Auth0, which is what Char sees. Security policies are enforced by the platform. MFA requirements, session duration, allowed authentication methods—these are configured in your auth platform, not inherited from Google. This is why the individual identity provider guides for Auth0, Logto, Better Auth, etc. all focus on configuring that platform as your IDP—even when users authenticate through upstream providers like Google or enterprise SAML.

​

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.

​

Remote MCP Servers (Private Beta)

The federated model can extend beyond user authentication to internal MCP servers. This feature—currently in private beta—uses your same IDP to obtain scoped tokens for internal services, so the user’s identity flows through the entire tool chain.

​

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