better-auth: Better Auth: The Auth Runtime That Refuses to Stay in One Framework

Auth That Moves

Most auth libraries fail at the seams. They work until you need a second runtime, a different ORM, a desktop shell, or enterprise features that were never part of the original design. Better Auth is interesting because it seems to start from the opposite assumption: auth should be a portable contract, not a framework trick.

That is why the project reads less like a login helper and more like an operating layer for identity. It tries to keep the core stable while adapters, plugins, and platform-specific packages absorb the mess that usually fractures authentication.

Why Auth Keeps Breaking at the Edges

The common failure mode is predictable. A library starts with OAuth and cookies, then gets pulled into 2FA, passkeys, organizations, SSO, SCIM, and multi-tenancy. At that point, the original abstraction starts leaking, because it was built for a narrow use case, not a living identity system.

One Core, Many Attachments

The repository structure makes the strategy obvious. There is a core package, then adapters for Drizzle, Prisma, Kysely, Mongo, and memory, plus plugins for organizations, two-factor auth, passkeys, API keys, and SSO. There are also platform-specific packages and demos for Expo and Electron, which tells you the core is not married to one deployment surface.

That modularity is not just neat packaging. It is the difference between a library that tolerates complexity and one that is built to absorb it. Better Auth separates the core auth contract from the concerns that usually contaminate it.

The Trick: Web Standards First

The portability story only works if the core speaks in web-native primitives. Better Auth leans into `Request` and `Response`, and its rules around `Uint8Array` instead of `Buffer` point in the same direction. That matters because Node-specific assumptions are exactly what break auth in edge runtimes and non-Node environments.

// The point is not the exact API shape.
// The point is that the contract stays web-native.

async function handleAuth(request: Request) {
  const session = await auth.getSession({ request });
  if (!session) return new Response("Unauthorized", { status: 401 });

  return new Response(JSON.stringify(session), {
    headers: { "content-type": "application/json" },
  });
}

That design choice explains why the same mental model can stretch across Next.js, edge workers, Electron, and Expo. The framework becomes a delivery surface, not the center of gravity.

The Core Contract Across Runtimes

Better Auth’s architecture can be understood as one contract with three moving parts. The runtime supplies the request, the core handles identity and lifecycle logic, and adapters or plugins fill in persistence and feature depth. The important thing is that each layer stays legible on its own.

That split also reduces the usual incentive to fork behavior per framework. If the same contract survives every surface, then edge, server, and desktop implementations can evolve without rewriting the auth brain each time.

What Makes It More Than Auth.js With Extras

The key difference is not just feature count. It is product shape. Better Auth bundles advanced identity capabilities as attachable modules, which makes the whole system feel like infrastructure rather than a toolkit of isolated recipes.

That is why comparisons with Clerk or Auth0 miss part of the story. Those products optimize for managed simplicity. Better Auth optimizes for ownership, portability, and a broad feature surface that still lives inside your stack.

Who This Is For, and Who Should Still Skip It

Better Auth is not the universal answer. Hosted auth still wins when convenience and delegation matter more than control. But if the strategic choice is to own identity as infrastructure, this project is aiming squarely at that problem.

Sources and Notes