Feature Status
Current support boundaries for identities, authentication methods, recovery, and OAuth.
Effect Auth is alpha software. Public contracts can change between alpha releases.
| Capability | Status | Boundary |
|---|---|---|
| Assurance v2 | Implemented | Built-in flows create versioned server evidence; core derives local AAL, canonical AMR, and per-method/per-factor freshness. UV-passkeys and TOTP can establish local aal2; recovery creates constrained remediation; built-ins never establish aal3. These tiers do not automatically claim NIST SP 800-63 conformance. |
| Identity-first accounts | Implemented | User is the stable subject; login identifiers are separate Identity records. A user can have multiple identities. |
| Identity namespaces | Implemented | Email is global. Username and registered custom kinds can be global or tenant-scoped. Scope and kind are explicit inputs. |
| Password authentication | Implemented | Sign-up and sign-in accept an explicit identity. Username-only accounts do not require email. |
| Email flows | Implemented | Verification belongs to an email identity. Email OTP, magic links, and password reset resolve global email identities. |
| Atomic registration | Implemented | Maintained storage creates the user, identity, and password credential in one transaction. Custom stores must provide the same boundary. |
| Recovery requirement policy | Implemented | Recovery is optional by default. Applications can require enrollment and receive a limited session with a typed recovery requirement. |
| Identity management | Implemented, opt-in | IdentityManagement, IdentityHttpApiGroup, and createIdentityClient provide availability, list, add, replace, revoke, and primary-login operations. HTTP ownership comes from the current session; applications provide mutation and step-up policy. |
| Durable authorization | Implemented, opt-in | Scoped permission/role grants, CAS-protected definitions, maintained SQLite/D1 storage, and audit projections are available. Permission-definition HTTP administration and its client are standalone; the application must provide authorization, which runs before every lookup or mutation. ABAC, ReBAC, tenant mapping, and grant-administration HTTP remain app-owned. |
| OAuth identity bridge | Implemented | Resolution checks (providerId, providerAccountId) first. Policy may create an email-less user or trust a verified provider email; collisions require explicit linking, and maintained storage atomically creates the user, optional email identity, and provider account. |
| Phone identity | Deferred | There is no first-party phone/SMS module. A custom kind does not add E.164 normalization, verification, delivery, or recovery semantics. |
No compatibility payloads or legacy email columns are supported by the identity-first API and schema.
Assurance v2 likewise has no compatibility/backfill path for earlier alpha session and TOTP rows. Its baseline migrations were rewritten; reset alpha development databases before applying the current migration set.
Identity mutations use expectedUpdatedAt compare-and-set guards. A user cannot revoke their last login-eligible identity. Added email identities start unverified; username and custom identities are locally verified, and revoked/replaced usernames become immediately reusable. Availability is advisory: the atomic uniqueness constraint remains authoritative.