Skip to main content
Char uses an SSO-first approach to authenticate end users. Your users authenticate through your existing identity provider and access the AI agent seamlessly—no separate credentials required.
Char validates tokens on behalf of your application. You configure your application’s OIDC client ID in the Char dashboard. Char then validates that incoming tokens were issued for your application—ensuring only your users can access your agent, not users from other applications in your IDP.

​
How It Works

1

User authenticates with your IDP

When a user accesses your application, they authenticate through your existing identity provider (Okta, Azure AD, Auth0, Google, or any OIDC provider).
2

Your app receives a JWT token

Your IDP issues a signed JWT token containing the user’s identity (sub claim) and other claims.
3

Agent validates the token

When initializing the Char agent, pass the user’s JWT token. Char validates the token against your IDP’s public keys (JWKS) and extracts the user identity.
4

Secure, seamless experience

The agent authenticates the user without additional login steps. Usage is tracked per-user based on their IDP identity.

​
Supported Identity Providers

Okta

Enterprise identity management with Okta Identity Cloud

Azure AD

Microsoft Entra ID (formerly Azure Active Directory)

Auth0

Flexible authentication platform by Okta

Google Workspace

Google Workspace and Google Cloud Identity

WorkOS

WorkOS User Management and AuthKit

AWS Cognito

Amazon Cognito User Pools for AWS applications

Firebase Auth

Firebase Authentication for web and mobile apps

Clerk

Developer-focused authentication platform

Scalekit

Full Stack Auth, SSO, SCIM, and MCP Auth

Better Auth

Open-source TypeScript auth framework

Logto

Open-source OIDC platform for SaaS and AI apps

Keycloak

Open-source identity and access management

OneLogin

Enterprise identity management platform

Ping Identity

PingOne and PingFederate integration

Custom OIDC

Any OpenID Connect compliant provider

​
Security Model

Char’s SSO integration is built on security best practices:
FeatureImplementation
Token validationAsymmetric signature verification using IDP’s public keys (JWKS)
Issuer validationTokens must come from the configured IDP’s issuer URL
Audience validationTokens must include your configured client ID in the aud claim
No shared secretsOnly public key cryptography - no client secrets stored
Token handlingTokens are validated, claims extracted, then discarded - never persisted
Audience validation is critical. If your IDP is used by multiple applications, without audience validation an attacker could use a token from another app to access your Char agent. Always configure the Client ID (audience) in your Char dashboard.

​
Configuration Overview

Every IDP requires:
  1. Provider Type: Select your IDP (Okta, Azure AD, Auth0, Google, WorkOS, or Custom OIDC)
  2. Client ID: Your OIDC application’s client ID (used for audience validation)
  3. Domain/Issuer: Provider-specific identifier (see details below)
  4. Allowed Domains: Origins where your agent can be embedded
Enter your Okta domain without the https:// prefix.Example: acme.okta.com or acme.oktapreview.comChar constructs the issuer URL as https://{domain} and fetches JWKS from the standard discovery endpoint.
Enter your tenant ID or primary domain.Example: contoso.onmicrosoft.com or 12345678-1234-1234-1234-123456789abcChar constructs the issuer URL as https://login.microsoftonline.com/{tenant}/v2.0.
Enter your Auth0 domain without the https:// prefix.Example: acme.auth0.com or acme.us.auth0.comChar constructs the issuer URL as https://{domain}/ (trailing slash required by Auth0).
No domain configuration needed. Google uses a fixed issuer URL.Just provide your OAuth Client ID from the Google Cloud Console.
Enter the full issuer URL from your WorkOS dashboard.Example: https://api.workos.com/sso/authorize/conn_...
WorkOS requires manual aud claim configuration in your connection settings.
Enter your Scalekit environment URL as the issuer.Example: https://your-app.scalekit.comChar discovers the JWKS endpoint from {environment_url}/.well-known/openid-configuration.
Enter your Better Auth base URL as the issuer.Example: https://auth.yourapp.comRequires OIDC Provider and JWT plugins. JWKS endpoint is at /api/auth/jwks.
Enter your Logto endpoint followed by /oidc.Example: https://your-tenant.logto.app/oidcChar discovers the JWKS endpoint from {endpoint}/oidc/.well-known/openid-configuration.
Enter the complete issuer URL for your OIDC provider.Example: https://auth.example.com/realms/mainChar appends /.well-known/openid-configuration to discover endpoints.

​
Agent Integration

Once your IDP is configured, pass the user’s JWT token to the agent using the connect() method: 
import "@mcp-b/char/web-component";
import type { WebMCPAgentElement } from "@mcp-b/char/web-component";

const agent = document.querySelector("char-agent") as WebMCPAgentElement
  ?? document.createElement("char-agent") as WebMCPAgentElement;

if (!agent.isConnected) {
  document.body.appendChild(agent);
}

// Use connect() - keeps token out of DOM
agent.connect({ idToken: currentUser.idToken, clientId: "your-oidc-client-id" });
The agent automatically validates the token against your configured IDP and establishes the user session.
For detailed integration instructions, see the Embedding the Agent guide.

​
Alternative: SSR Applications

For server-side rendered applications (Next.js, Remix, Rails, Django), you may not have access to the JWT client-side. Instead, exchange your IDP token for a short-lived ticket server-side, then pass it to the client. Tickets let your backend validate users with your existing auth system, then create a short-lived, single-use ticket without exposing your IDP’s JWT to the client.

SSR Authentication Guide

Learn how to embed the agent in server-rendered applications using ticket exchange

​
Testing Your Configuration

The Char dashboard includes a Test Connection feature that verifies your IDP configuration by fetching the OIDC discovery document. This confirms:
  • The IDP is accessible
  • The discovery document is valid
  • The JWKS endpoint is available