authbase

In development · self-hosted · Apache-2.0

Authentication you run yourself.

One binary and one PostgreSQL hold the users of every product you build. Your backend signs them up and logs them in with an API key, then verifies their tokens locally. authbase is never on your hot path.

Early preview. authbase is in active development and already runs in production for its author. The source code and packages are not public yet; this site introduces the project and documents how it works ahead of the first public release.

import { Authbase } from "@authbase/node";
import { requireAuth } from "@authbase/node/express";

const authbase = new Authbase({
  url: process.env.AUTHBASE_URL!,
  apiKey: process.env.AUTHBASE_API_KEY!,
});

app.post("/login", async (req, res) => {
  const tokens = await authbase.auth.login({
    identifier: req.body.email,
    password: req.body.password,
    client_ip: req.ip,
  });
  res.json(tokens);
});

// Verified locally against the app's JWKS
app.get("/me", requireAuth(authbase), (req, res) => {
  res.json({ id: req.auth!.sub, roles: req.auth!.roles });
});

How it fits

authbase owns your users' credentials and issues their tokens. Your product keeps its own database and logic.

  1. ClientBrowser or mobile appTalks only to your backend. Never sees the API key.
  2. Your backendVerifies every request locallyChecks the access token against the app's public keys, fetched once and cached.
  3. authbaseSign-up, login, refresh, logoutUsers, passwords, signing keys and the audit log, in PostgreSQL.

What you get

Off the hot path

Access tokens are EdDSA JWTs your backend verifies in-process against a cached JWKS. A request with a valid token never waits on authbase.

Secure without configuration

Argon2id, the 100,000 most common leaked passwords refused, per-IP and per-key rate limits, lockout, refresh-token reuse detection and an audit log.

Standard, not clever

RFC 9068 access tokens, a JWKS and OIDC discovery document per app, RFC 9457 errors with stable codes, and an OpenAPI spec for all of it.

Every product isolated

Each product is an app with its own users, keys, issuer and settings. One instance serves all of them; nothing leaks between apps.

Email flows included

Password reset, email verification and security notices, with hosted pages that work without JavaScript, or links to your own pages.

Boring to operate

One binary, PostgreSQL 16+, one master key. A dashboard for apps, keys, users and the audit log; runbooks for backups, upgrades and key rotation.

SDKs for Node (Express, Hono, Next.js) and Kotlin/JVM (Ktor, Spring Boot). Go, Python and everything else: JSON over HTTP and a JWT library.

Written for coding agents, too

Point your agent at the docs and it gets plain markdown, the full API contract and the rules that keep an integration safe. With Claude, install the skills and ask it to add authbase to your app.

Docs for agents

Where it stands

  1. DoneCore API, email flows, dashboard, SDKsEverything on this page, in production use by its author.
  2. LaterTeams and hosted loginShared apps, and a hosted login page with the OAuth 2.0 code flow and PKCE.
  3. LaterMFA, social login, webhooksMulti-factor authentication for users and the dashboard, social providers, events.

Read how it works

The quick start shows the whole flow: start authbase, create an app, and put an example backend on it.