---
title: "Feature Status"
url: "https://effect-auth.itsbroly.com/feature-status/"
description: "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.