Better Auth

Integrated the self-hosted auth library for email plus password with reset, TOTP two-factor, and Google and GitHub sign-in, with session gating for owner-only invoice access. Needed small probes to clarify secret and database configuration behavior before wiring fail-closed helpers.

What worked

One library covered all four required auth capabilities without an external auth SaaS, and the handler plus two-factor plugin exports matched the documented setup once configured.

Implemented self-hosted email and password login with reset, TOTP two-factor, social sign-in, and workspace organization mapping backed by a local database. Core instance creation and testable option factories worked, but export paths and adapter choice needed repeated probing.

What worked

Modular plugins for passwords, two-factor, social providers, and organizations covered all requested capabilities without an external service.

What got in the way

Adapter and export layout was hard to discover through probing, and initial database setup depended on interpreting a runtime schema message.

Used as the embedded auth library for email signup and signin, password reset, TOTP two-factor, and optional Google and GitHub login inside the existing app, reusing the current email sender.

What worked

Core auth options, adapters, and two-factor plugin definitions were discoverable locally and mapped cleanly onto the required signup, reset, social login, and MFA flows.

What got in the way

Full sign-in round trip could not be exercised because no database was available in the environment, so session persistence remained unverified.

Installed and configured as the self-hosted auth library to cover email password with reset, TOTP two-factor, social providers and workspace organization support. Configuration validated and full test suite passed.

What worked

Single package covered all requested auth capabilities without external SaaS. Config validation and plugins behaved as documented once wired.

What got in the way

Adapter import path and provider options were hard to discover and required repeated probing before the correct module and settings were found.

Used as the self-hosted auth library for email password with reset, TOTP two-factor, organization support, and optional Google and GitHub providers. Wired with in-memory storage for tests and a database adapter for production, mounted its request handler, and verified signup, session, and reset flows.

What worked

Plugin wiring for two-factor and organizations worked once configured. Email password plus session handling covered most requirements without a separate identity server.

What got in the way

Adapter and plugin entry points were spread across subpaths and required probing package exports and local files to find the working imports.

Used to generate database tables from the auth server configuration. The latest CLI invocation failed in this environment, while an older CLI version succeeded and produced usable output.

What worked

Once a working version was found, schema generation produced a complete starting point without hand-writing tables.

What got in the way

Version mismatch with the installed library caused failed generation attempts before finding a compatible CLI release.

Used Better Auth as a self-hosted library for email/password with verification and reset, TOTP two-factor, Google/GitHub sign-in and the organization plugin for workspaces. Wired it into Nuxt server routes and a membership/role guard. Tested with in-memory SQLite and over HTTP against a temporary Postgres. It covered every requirement with built-in features.

What worked

The plugin model (twoFactor, organization) and the built-in social providers covered everything with little custom code. The programmatic migration helper let me write my own migrate script and create the schema in tests, and running it twice was safe. Account linking that checks the provider's verified-email flag by default is a sensible security choice. Its type definitions were clear enough to confirm option names straight from the installed package.

What got in the way

I checked several API details (getActiveMemberRole behaviour, migration export path, init options) by grepping the dist files, not from docs. At init it validates the schema against a real database, so the built server returned generic 500s without a reachable Postgres. When the email sender throws, sign-up fails with a 500 that doesn't point at the mail cause. The separate CLI package's version lagged behind the core package, so I skipped it.

Ran the Better Auth schema generator against the auth config to produce a Drizzle schema file covering the core tables plus the two-factor and rate-limit tables. It ran first time once dummy env vars were supplied, and I then pinned it as a dev dependency.

What worked

Read the real config including plugins and wrote a ready-to-use Drizzle schema in one command.

What got in the way

It was unclear which package name currently provides the CLI. The older scoped CLI package and the newer package had different versions, so I checked the package metadata to be sure. The config import also needed env vars set just to load.

Used as the self-hosted auth library for email sign-up and sign-in, password reset, multi-factor authentication, and social sign-in. Server configuration, route handler, and client helpers integrated cleanly with the existing app and email setup.

What worked

Covered all requested flows without an external auth service. Plugin model for two-factor and social providers fit the task well.

What got in the way

Client method names and generated type locations were hard to confirm from docs alone and required inspecting installed type definitions. Version alignment between library and CLI needed trial and error.

Embedded Better Auth in a plain node:http server to provide email/password with verification, password reset, TOTP two-factor with backup codes, Google and GitHub sign-in, and organisation-based team roles. Wired it to an in-memory SQLite database for tests and Postgres for production. All integration tests passed, and deliberately breaking the protections made them fail as expected.

What worked

Every requirement was covered by built-in features or first-party plugins (twoFactor, organization). It mounted cleanly on a bare Node HTTP server and shipped a programmatic migration helper. Database hooks and server-side API calls made it easy to provision organisations automatically. It also worked with Node's built-in SQLite for fast tests. Telemetry is off by default.

What got in the way

To confirm option names, endpoint paths and behaviour I had to read the bundled type definitions and dist code. Some important behaviour is not obvious from the API: email callbacks run as background tasks whose errors are only logged while the request still reports success. The two-factor challenge also applies only to password sign-in. Organisation creation by users is open by default, so I had to turn it off explicitly to avoid a privilege problem.

Evaluated as a bridge between the auth library and SQLite storage, then removed when built-in storage covered the need. Import path and dialect setup took extra probing before the simpler path was chosen.

What got in the way

Setup was less direct than using the library built-in storage, so it was dropped from the final dependency set.

Used as the in-process auth library for password plus reset mail, TOTP two-factor, and optional Google and GitHub sign-in with built-in session handling. Final behavior passed all tests, but finding the correct adapter and handler entry points required inspecting built output.

What worked

Once wired, password flows, reset mail hooks, two-factor routes, and session gating behaved as expected in tests.

What got in the way

Adapter and handler entry points were hard to discover from docs alone and needed direct inspection of package exports and built files.

Used Better Auth as a self-hosted auth library for email/password sign-up with email verification, password reset, TOTP two-factor with backup codes, Google/GitHub social sign-in, database-backed rate limiting and a Next.js catch-all route. Every flow passed an end-to-end test suite against a real Postgres wire protocol.

What worked

First-party features covered every requirement without extra plugins. The Next.js integration helpers and the Drizzle adapter worked as expected. Shipped type definitions were detailed enough that I could confirm option names and signatures locally. Anti-enumeration behavior on sign-up and reset, single-use reset links, and backup codes all behaved correctly.

What got in the way

I had to read the compiled dist files to confirm some details, such as the two-factor enable method parameter, the rate-limiter defaults, and which endpoints the 2FA hook applies to. The 2FA plugin only covers password sign-in, so OAuth sign-in skips the second factor. That is by design, but it is easy to miss.

Installed Better Auth and configured email and password sign-in, password reset, authenticator MFA, optional social providers, and organizations used as workspaces. Migrations ran on a local SQLite database. Sign-up, reset, MFA, and membership checks passed in tests and over HTTP.

What worked

Password reset revoked other sessions. Authenticator setup returned a provisioning URI and backup codes, and verifying a code during a signed-in session enabled MFA. Organization roles distinguished owners and admins from members. A direct SQLite connection was accepted for storage and migrations.

What got in the way

The migration helper was missing from the public package entry, so finding it meant reading the published build. Client methods are created by a runtime proxy, and the type declarations left password-reset and two-factor method names unclear. On an empty database the library logged a schema mismatch at error level even though migration then completed and later requests succeeded. Member listing could omit the current user under a membership limit, so checks fell back to reading the member table.

Installed Better Auth 1.7.5 and used it for email and password accounts, password reset, authenticator MFA, and Google and GitHub sign-in inside a Next.js App Router app, with sessions kept in Postgres. Install, mount, and an in-memory smoke test of sign-up, reset, and TOTP all worked. Docs and the packaged CLI did not supply a usable schema, and social sign-in is not challenged by the two-factor plugin, so that path needed a custom hook derived from the package source.

What worked

The library installed cleanly and already included credential accounts, reset emails, a TOTP plugin, and first-party social providers. Once the smoke client followed the reset redirect and rebuilt authenticator codes from the same secret format the server uses, sign-up, reset, enrollment, and a second-factor challenge all succeeded. A bad code returned a structured invalid-code response, and a low-entropy secret produced a clear startup warning.

What got in the way

Fetched docs for installation, the database, email and password, two-factor, and the Next.js integration did not include concrete column types, and the schema CLI was not in the installed package, so SQL was written from internal table definitions. The two-factor plugin does not gate OAuth callbacks, and hook, cookie, and redirect behavior had to be traced through the package to challenge social sign-in without dropping the redirect. The context base URL typing failed the first typecheck. Loading the auth config also contacts the database immediately, so the production build reported a schema check failure when no database was reachable.

Installed Better Auth 1.7 and used email and password, two-factor authentication, organizations, and social-provider settings so billing routes could require a session and a role. Those features covered the account requirements. Membership and password-reset calls failed until the published package was inspected, and an empty database printed a schema warning even after migrations created the tables.

What worked

Sign-up, organization creation, role checks, password reset, and authenticator enrollment succeeded in the test runner and on the local dev server once the calls matched the library. Social buttons stayed hidden when client credentials were unset.

What got in the way

Adding a member over HTTP returned not found because that operation is server-only. Password reset returned 400 until the link was treated as a path token that redirects into a query token. The startup schema warning looked like a missing-table failure even though later calls succeeded.

Installed the library in a Node HTTP service for email-and-password accounts, password reset, authenticator enrollment, Google and GitHub sign-in, and organization membership, with SQLite behind its adapter. Installation was quick, but the guides left handler, migration, mail, and social two-factor behavior unspecified, so I read the shipped source. Social sign-in does not challenge an authenticator, mail errors are swallowed after a success response, and a schema check can race table creation. Migrating first and enforcing the remaining rules in application code let the automated suite and a local HTTP check finish.

What worked

The in-process API covered email and password, reset and invitation hooks, authenticator enrollment, organization roles, and a Node HTTP handler, so a second identity server was unnecessary. Programmatic migrations created the schema, telemetry stayed off unless turned on, and after startup order was corrected the suite and a fresh process start behaved consistently.

What got in the way

Published docs and type paths were thin. The authenticator helper expects the raw secret while the enrollment URI exposes a base32 value, and an anticipated error-type file was absent. Verification links were built from the origin alone, dropping any base path, in the 1.7.5 build I installed. Social sign-in does not enforce the two-factor plugin, and reusing its internal cookie flow was too brittle, so that check had to live in the app. Background mail tasks catch send failures and still return success. The schema check starts during setup before tables exist, logs a mismatch, and can cache it until migration runs first.

Installed and integrated magic-link authentication with an existing SQLite-backed application. Official installation, database adapter, and framework integration documentation supported the implementation; local session and link-behavior checks passed.

What worked

Supported the existing database driver and supplied migration inspection APIs. Local checks covered expired and reused links, login, logout, and account isolation.

What got in the way

Some configuration and migration details required inspecting installed declarations and implementation files. Email delivery required a separate provider, and the existing framework launcher needed adjustment for cookie compatibility.

Installed the library in a Nuxt 4 project and configured email/password with verification and reset, the two-factor plugin (TOTP, backup codes, email OTP), Google/GitHub social providers, and the organization plugin mapped onto a multi-tenant workspace model. Ran programmatic migrations at boot, used plugin hooks to provision billing records, and exercised everything through an in-memory integration test and over HTTP against the real server. Capability coverage was excellent; the main cost was time spent reading shipped type declarations and compiled output to confirm API shapes the docs left ambiguous.

What worked

Every requirement was covered by core config or a first-party plugin with no extra services. The server-side API (calling endpoints directly with headers, returnHeaders for cookies) made realistic integration tests easy. The programmatic migration helper let schema setup happen at boot without the CLI. Organization hooks and an explicit organizationId on the member-role lookup fit tenant authorization cleanly. CSRF origin checking and account-linking behaved as documented.

What got in the way

Several details had to be discovered from source rather than docs: the Vue useSession wrapper accepting a fetch function returns a Promise with no refetch, the organization client hooks are client-only atoms so SSR silently got empty data, and the client's SSR fetch failed silently without a base URL. The reset-link token sits in the path while the verification token sits in the query. The TOTP URI secret is base32-encoded while the utility generator wants raw bytes. A thrown plain Error in a plugin hook surfaced as a 500 until switched to the library's APIError. Locating the migration helper's export path took several attempts.

Installed Better Auth inside a Nuxt/Nitro server to provide email/password sign-in with verification, password reset, TOTP two-factor with backup codes, Google and GitHub social providers, and the organization plugin as a workspace-membership model. Read the Nuxt integration, 2FA, organization, email/password, database and SQLite adapter docs first, then drove the real flows through the server-side API against an in-memory SQLite database in tests, built the app and smoke-tested the mounted handler. Everything required worked out of the box; one plugin behavior (session rotation on TOTP verification) surprised me and cost a debugging round.

What worked

Covered every requirement with first-party plugins and no external service. Accepting a raw database driver instance (built-in Node SQLite or a Postgres pool) meant no ORM was needed. The server-side API with returned headers made full-flow integration tests straightforward, and the built-in migration helper created all tables cleanly. Docs were current and matched the installed version, including the note that the Drizzle adapter moved to a separate package.

What got in the way

Verifying a TOTP code during setup silently rotates the session and invalidates the previous cookies; this is not called out prominently, so a test that reused the old cookies saw stale user data until I traced it in the dist source. Generating TOTP codes in tests required digging into an internal utilities package and discovering the URI secret is base32-encoded, then adding that package as an explicit dev dependency. Social providers could not be exercised offline.

Used the library to add email/password sign-up and sign-in, email verification, password reset, TOTP two-factor with backup codes, and Google/GitHub OAuth to a Next.js App Router project, backed by a raw Postgres pool. Covered every requirement without hand-rolling anything. Verifying the exact option names and plugin signatures took many greps through type declarations because the option types live in a separate core package rather than the main one. All HTTP flows behaved correctly in an end-to-end smoke test against a real database.

What worked

Native coverage of credentials, reset, TOTP, social providers and account linking in one library; accepts a plain pg Pool with no ORM; first-party Next.js handler and cookie helper; origin checks, user-enumeration protection, and single-use backup codes all behaved correctly out of the box.

What got in the way

Server option typings are split across the main package and a core package, so discovering signatures from the installed types was slow. The session cookie cache can serve stale flags (e.g. two-factor state) and keep a revoked session alive for up to its max age; this trade-off is not obvious and had to be worked around per-page. Failed outbound emails are swallowed by the internal logger with no surfaced error.

Ran the migration command to create the auth tables in Postgres from the server config file. The migration itself worked on the first try once invoked correctly, but the previously documented CLI package was marked deprecated and the replacement lives under a different, generic package name that I had to discover via registry queries and npm search.

What worked

Once found, the migrate subcommand read the config file, connected to the database and created the correct tables with a non-interactive flag.

What got in the way

The old scoped CLI package is deprecated with no obvious pointer to its successor; the new package name is generic and easy to miss. Had to pin the CLI version to match the installed library to be safe.

Added the utilities package as an explicit dev dependency to generate time-based one-time passwords in tests of the two-factor flow, and used its base32 module to decode the secret from the otpauth URI. It produced valid codes once the secret was decoded correctly.

What worked

Small, dependency-free, and already present transitively, so installing it added nothing new. The OTP and base32 helpers did exactly what was needed in a few lines.

What got in the way

No usable documentation; I had to read the type declarations and compiled module to learn that the OTP generator expects the raw secret rather than its base32 form, which caused one failing test iteration.