theAuth
Star Quickstart

Use case

Auth for AI startups

Sign-in on day one, agent identity when your product starts calling tools, and enterprise features when the first large customer asks, all from one MIT licensed library you can read.

Read the quickstart Jump to the steps

The problem

You need auth now, and a different auth later.

Early on, auth should cost an afternoon, not a sprint. A few weeks later your product has agents calling tools, and a user table is not enough. Later still, a company asks for SSO.

Switching auth providers at each stage means migrating users three times. The alternative is a library whose scope grows with you, that runs on the runtime you already deploy to, and whose licensing does not change as your user count does.

The theAuth path

Scaffold, deploy anywhere, add features as needed.

Scaffoldcreate-theauth-app
npx @glinr/create-theauth-app asks for a directory, a template and a database driver, writes the project and installs dependencies. Templates today: next-saas and hono-mcp.
AdaptersNext.js, Hono, more
Adapters exist for Next.js, SvelteKit, Nuxt, Hono, Express, Fastify, Astro, NestJS, SolidStart and TanStack Start. Hono runs on Cloudflare Workers, Bun and Deno.
Edge runtimesWorkers, Deno, Bun
The TypeScript core runs on Cloudflare Workers, Deno and Bun without code changes and has three runtime dependencies: drizzle-orm, jose and zod. Databases are SQLite, PostgreSQL, MySQL and Cloudflare D1.
LicensingMIT
The library is MIT licensed. There is no per-user fee for software you run yourself. theAuth Cloud, the hosted option, is in early access and has no published prices.
Growth pathsame library
Agents with scoped permissions and an audit trail, organizations with RBAC, SAML and OIDC SSO and SCIM are modules of the same library. Details on the B2B SaaS page.
theAuth runs as a library inside your own app, mounted through a framework adapter, with your own database behind it (Postgres, MySQL, SQLite or Cloudflare D1). You run the whole stack in your infrastructure, and identities stay in your database.

Step by step

From an empty folder to a running app.

Scaffold first, then add the pieces your product needs.

  1. Scaffold the app

    Pick next-saas for a Next.js App Router app with Drizzle and prebuilt sign-in components, or hono-mcp for a Hono server that also acts as an MCP authorization server. The database driver is better-sqlite3 by default, or pg for Postgres.

    terminal
    npx @glinr/create-theauth-app
cd my-theauth-app
pnpm install
cp .env.example .env   # then set THEAUTH_SECRET
pnpm db:push
pnpm dev

  2. Create the instance

    This is the core. Pick the plugins your sign-in needs. Postgres here, SQLite works the same way for local development.

    lib/auth.ts
    import { createTheAuth } from "@glinr/theauth";
import { emailPassword, passkey } from "@glinr/theauth/auth";

export const auth = await createTheAuth({
  database: { provider: "postgres", url: process.env.DATABASE_URL },
  plugins: [emailPassword(), passkey()],
});

  3. Mount it in Next.js

    A catch-all App Router route hands every auth path to the adapter. The default base path is /api/theauth, so pass basePath if you want a different one.

    The adapter packages are @glinr/theauth-nextjs and @glinr/theauth-hono.

    app/api/theauth/[...theauth]/route.ts
    import { theAuthNextjs } from "@glinr/theauth-nextjs";
import { auth } from "@/lib/auth";

const handlers = theAuthNextjs(auth);

export const GET = handlers.GET;
export const POST = handlers.POST;
export const PATCH = handlers.PATCH;
export const DELETE = handlers.DELETE;
export const OPTIONS = handlers.OPTIONS;

  4. Or run it on Hono at the edge

    The same instance mounts in a Hono app, which uses web-standard Request and Response.

    src/index.ts
    import { Hono } from "hono";
import { theAuthHono } from "@glinr/theauth-hono";
import { auth } from "./auth";

const app = new Hono();
app.route("/api/auth", theAuthHono(auth));

export default app;

  5. Give your first agent an identity

    When your product starts calling tools, add an agent with scoped permissions. See identity and permissions for AI agents for delegation, approvals and budgets.

    agent.ts
    const agent = await auth.agent.create({
  ownerId: "user-123",
  name: "github-reader",
  type: "autonomous",
  permissions: [{ resource: "mcp:github:*", actions: ["read"] }],
});

Checked against the package source and the scaffolder's README for @glinr/theauth 0.5.0 and @glinr/create-theauth-app 0.2.0 on 2026-10-06. The scaffolder's README also lists npm create theauth-app@latest and bunx @glinr/create-theauth-app as equivalents. Not every plugin runs on every runtime, so check the adapters docs before you commit to one.

Pitfalls

Early-stage mistakes worth avoiding.

  • A placeholder secret in production.Templates use .env.example with an empty THEAUTH_SECRET. Set a long random value and keep it out of git.
  • Local SQLite in a serverless deploy.A file database does not persist on most serverless hosts. Use Postgres, MySQL or Cloudflare D1 there.
  • Mounting the adapter at a path you did not configure.The Next.js adapter strips its basePath, which defaults to /api/theauth. Pass the real path if you mount elsewhere.
  • Adding agents without an owner.Every agent needs an ownerId. Decide who owns an agent your product creates on a user's behalf before you ship it.
  • Planning a later migration.SSO and SCIM are modules of the same library. Adopt organizations early and the enterprise step is configuration, not a user migration.

Get started

Give your first agent an identity.

Install the package, create an agent with scoped permissions, and read its first audit record. The core runs on Postgres, SQLite, MySQL or D1, and the Go module needs a single go get.

Read the quickstart View on GitHub
  • npm install @glinr/theauth
  • go get github.com/glincker/theauth-go
Or skip hosting with theAuth Cloud