Authentication

Who uses what

• End users of your app: never Invoker OIDC. They receive LiveKit join tokens (and ICE config) from your backend, which calls Invoker with a tenant API key.
• Your backend: Authorization: Bearer <public_key>:<secret> on tenant routes.
• Developers / operators who manage keys in the browser: sign into the operator console via Arca (Authentik). Either an admin links their OIDC sub to a tenant, or you enable auto-provision on the API (see below).

Tenant machine auth

All tenant routes require:

Authorization: Bearer <public_key>:<secret>

The secret is only shown when the key is created. Store a hash or the secret in your vault — never in client-side code.

Admin operations

Internal operators use:

X-Admin-Key: <ADMIN_API_KEY>

to create tenants, issue keys, link console operator identities (OIDC sub from Arca), and disable tenants.

Link console operators (Arca / Authentik) to a tenant

POST /v1/tenants/{tenant_id}/identities with JSON:

{
  "subject": "<oidc sub from Authentik>",
  "email": "user@example.com"
}

After linking, that operator can open the web console (Next app), sign in with Arca, and manage keys via /v1/console (server-to-server from the Next app using CONSOLE_SERVICE_SECRET and X-Authentik-Sub). This flow does not apply to your product’s end users.

Optional: auto-provision tenants (console)

If the control plane has CONSOLE_AUTO_PROVISION_TENANTS=true, the first successful /v1/console/* request for a new OIDC sub creates a new tenant and links that sub in one database transaction (no admin POST /identities first).

• CONSOLE_AUTO_PROVISION_EMAIL_DOMAIN (optional): if set to e.g. example.com, only emails at @example.com (or subdomains) are allowed; the Next app must send X-Authentik-Email (included when the Arca session has an email).
• Rate limit: auto-provision is throttled per client IP to reduce abuse if CONSOLE_SERVICE_SECRET leaked.

Default is off — use manual linking in production unless you trust everyone who can sign into Arca for this app.