Skip to content

Roadmap and product boundaries

What this library aims to cover today, what it deliberately does not include, and likely directions for future work.

In scope today

Registration, login/logout, email verification and password reset, Bearer / cookie / API-key transports, JWT / database / Redis / API-key strategies, guards, role-derived permission authorization, optional user CRUD, TOTP, OAuth login and account linking, rate limiting, per-account password-login lockout, hooks, configurable login identifier (email or username). See Features on the home page.

Opt-in multi-tenant organizations (roadmap #10) are complete for the library's intended scope: global User plus OrganizationMembership, tenant resolution, verified current-organization context, organization-scoped roles and permissions, JWT active-organization switching, operator administration (HTTP and CLI), and email invitations. Configuration, HTTP routes, security posture, and extension points are documented in Organizations. The library does not send invitation email; applications deliver the raw token from on_after_organization_invitation. Application-table data isolation remains the application's responsibility: the library does not add tenant foreign keys, mutate application queries, or filter application-owned tables.

Opt-in per-account brute-force protection is delivered for plugin-owned password login through AccountLockoutConfig. The library ships digest-only account keys, process-local in-memory storage for single-worker deployments, Redis-backed shared storage for multi-worker deployments, generic non-enumerating login failures for locked accounts, and independent composition with auth endpoint rate limiting.

Explicitly out of scope (library core)

  • Built-in email transport (use hooks).
  • UI or admin panel.
  • Full RBAC policy framework, including permission matrices, policy DSLs, built-in DB-backed permission catalogs, or multi-tenant authorization semantics. The shipped role / user_role tables remain the persistence layer behind flat role membership; role_permissions and custom permission_resolver objects are the current extension points for effective permissions.
  • Automatic row-level filtering or isolation helpers for application-owned tables. Applications remain responsible for tenant foreign keys, query scoping, and database isolation on their own domain tables.
  • WebAuthn / passkeys.
  • Built-in audit log storage.
  • End-user session dashboard API.

Product evolution

Planned directions include: production-first durable JWT denylist defaults, operator tooling around the documented Fernet keyring rotation helpers, audit trails, WebAuthn, richer RBAC policy tooling, DB-backed permission resolution helpers, session management APIs, and optional guidance or helpers for application-table isolation. Timelines are not committed here.

Definition of done (feature-level)

A feature is complete when it ships with HTTP flows, tests where appropriate, documented configuration, stated limitations for security-sensitive behavior, and documented extension points without requiring a fork.