Char uses an SSO-first approach to authentication. Rather than managing user credentials ourselves, we trust your existing identity provider to authenticate users. This page explains why this design is more secure and how it works.
Why SSO-First?
Traditional SaaS products ask you to create yet another username and password. This creates problems:
- Password fatigue: Users reuse passwords across services
- Credential silos: Each service stores credentials that can be breached
- Inconsistent security: Different services have different password policies
- No centralized control: You can’t revoke access from one place
SSO-first solves these problems by delegating authentication to your identity provider—the same system that already manages your users.
How Token Validation Works
When a user interacts with the Char widget, here’s what happens:
The key insight: Char never sees user credentials. We only see signed tokens, and we verify them using your IDP’s public keys.
Asymmetric Cryptography
JWT tokens are signed using asymmetric cryptography:
This means:
- Char doesn’t need your IDP’s secrets
- We can’t forge tokens
- Tokens can’t be tampered with (signature would fail)
What We Validate
When Char receives a JWT token, we check:
| Claim | Validation | Purpose |
|---|
iss (Issuer) | Must match your configured IDP | Prevents tokens from other providers |
aud (Audience) | Must include your Client ID | Prevents tokens meant for other apps |
exp (Expiration) | Must not be expired | Prevents replay of old tokens |
sub (Subject) | Must be present | Identifies the user |
| Signature | Must verify against JWKS | Ensures token wasn’t tampered with |
Why Audience Validation Matters
Audience validation is critical when your IDP serves multiple applications.
aud claim doesn’t match App B’s Client ID, so it’s rejected.
Always configure your Client ID in the Char dashboard to enable audience validation.
No Shared Secrets
A common pattern in other integrations is sharing a “client secret” between services. Char doesn’t do this.
| Approach | Secrets Stored | Breach Risk |
|---|
| Client Secret | Secret in Char servers | If we’re breached, attacker gets your secret |
| SSO-first (Char) | Only public keys | Public keys can’t be used maliciously |
Token Lifecycle
Tokens are ephemeral:
We don’t persist tokens. Each request validates its token independently. This means:
- No token database to breach
- Revoking access at your IDP takes immediate effect
- Token rotation is handled by your IDP
Revoking Access
Because authentication is delegated to your IDP, you control access:
- Disable a user in your IDP → They can’t get new tokens → Widget stops working
- Rotate signing keys in your IDP → Old tokens become invalid → Char fetches new JWKS
You don’t need to coordinate with Char to revoke access. Your IDP is the single source of truth.
Best Practices
- Always configure Client ID: Enables audience validation
- Use short token lifetimes: Reduce window for token misuse
- Implement token refresh: Keep users authenticated without long-lived tokens
- Monitor IDP logs: Detect suspicious authentication patterns
- Use HTTPS everywhere: Prevent token interception in transit
Summary
The SSO-first model offers several security advantages:
- No password storage: We never see or store user credentials
- Public key only: No shared secrets to compromise
- Centralized control: Your IDP is the authority
- Immediate revocation: Changes at your IDP take effect immediately
- Defense in depth: Multiple validation checks (issuer, audience, expiration, signature)
This approach means adding Char doesn’t increase your security attack surface—you’re just extending trust from your existing identity infrastructure.
