Riven Auth
LiveIdentity for every Riven surface, built on BetterAuth with Microsoft Entra ID as the enterprise directory.
Riven Auth is the identity layer behind every surface. It is built on BetterAuth, with Microsoft Entra ID as the directory for organisations that federate their identity. One session works across Console, Chat, Computer, Studio, Docs, and the rest of the shell.
The identity provider is Riven Auth (BetterAuth + Entra ID). If you find documentation, diagrams, or code comments elsewhere referring to “Logto”, that is stale — it is not the system in use.
The two paths#
| Path | Who uses it | Mechanism |
|---|---|---|
| Self-serve | Individuals and small teams | BetterAuth email and social sign-in, sessions issued by Riven |
| Federated | Enterprise and Group tiers | OIDC against Microsoft Entra ID, with group claims mapped to Riven roles |
Federated organisations additionally provision and deprovision members through Riven SCIM Proxy. Provisioning and authentication are separate concerns: SCIM decides who exists, Riven Auth decides who is signed in right now.
Sessions and API keys#
- Sessions authenticate a human in a browser. They are short-lived, refreshed transparently, and scoped to the organisation the user is acting in.
- API keys (
rvn_) authenticate a program. They never expire on their own but can be rotated or revoked — see Authentication & keys. - A session can mint a key; a key can never mint a session. That asymmetry is deliberate — a leaked key cannot be escalated into interactive access.
Roles#
| Role | Can do |
|---|---|
| Member | Use surfaces, hold personal keys, consume the organisation quota |
| Developer | Issue and rotate keys for the organisation, read usage telemetry |
| Admin | Manage members, roles, routing policy, and billing |
| Owner | Everything, plus tier changes and organisation deletion |
For federated organisations, roles come from directory group claims rather than being assigned in Riven, so the directory stays authoritative.
Where credentials live#
Riven Auth never stores a raw secret in its own tables. Client secrets, signing material, and issued key hashes are held by Riven Keymaster. Authentication events are recorded in Riven Telemetry and surfaced for audit through Riven Trust.