Overview
Server-to-server integration via Client Keys — when to use them, how to scope them safely.
Integrations covers everything that authenticates against Febasi Auth without a user JWT — backend services, scheduled jobs, third-party connectors, BFFs, and the public-signup proxy pattern. The mechanism is Client Keys (API Keys): long-lived credentials with explicit scopes, optional tenant restrictions, and per-key allowlists for origin and source IP.
When you reach for a Client Key
| Situation | Use a Client Key |
|---|---|
| A backend service consumes Febasi Auth on behalf of one tenant. | tenantAccessLevel: specific, tenant-owned. |
| A public signup page in a tenant's app. | Narrow scope (users:create), kept in the tenant's backend proxy. |
| A scheduled job that rotates secrets or audits keys. | Narrow scope, with expiresAt. |
A user-facing flow (login, refresh, /me, /register-from-admin) should use a JWT — Client Keys are for the gap a JWT cannot cover.
What's in this topic
Client Keys
Create, use, rotate, and revoke Client Keys. Includes scopes, tenant access levels, allowedOrigins, allowedIps, and usage logs.
Summary
Cheat sheet: the create-key body, the headers a key must send, the four common errors.
Related
- Concepts → CORS — per-key origin allowlist overrides the tenant.
- Concepts → IP allowlist — per-key source-IP allowlist as defense in depth.
- Registration → Overview — the canonical public-signup proxy pattern.