Authentication
Authentication
One identity system covers every surface. Falcata ID (id.falcata.io) signs humans in; everything programmatic — REST, MCP, CLI — authenticates with a bearer token bound to a user; and what any credential may do is decided by the same permission checks the human interfaces use.
The pieces, in the order you'll meet them:
- Falcata ID — magic-link sign-in shared by every Falcata product. Each app holds its own session, identity is federated through short-lived signed tokens, and one action signs you out everywhere.
- Personal access tokens —
fpat_…bearer tokens that can only narrow your own authority: read-only, namespace allowlists, permission allowlists, expiry. - Device authorization — RFC 8628 flow for CLIs and agents: short code, browser approval, token. This is what
furnace auth logindoes. - OAuth 2.1 + PKCE — authorization-code flow with dynamic client registration for third-party apps that can drive a browser redirect.
- Permissions, entitlements, and flags — what an authenticated identity can actually do, and why "not authorized" and "not in your plan" are different answers.
In this section
Falcata ID
How sign-in works: magic links, per-app sessions, sign out everywhere.
Personal access tokens
Bearer credentials that can only narrow what your account may do.
Device authorization
The RFC 8628 flow for CLIs and agents: short code, browser approval, token.
OAuth 2.1 + PKCE
Authorization-code flow with dynamic client registration for third-party apps.
Permissions, entitlements, and flags
The four layers that gate what an identity can see and do.