go-dev-auth ships a zero-dependency, better-auth-style authentication stack for Go

A full identity stack in one standard-library package

A new open-source authentication library for Go, go-dev-auth, landed on Hacker News's front page on 11 October 2026 with an unusually broad pitch: a complete identity stack — password logins, social sign-on, sessions, two-factor authentication, passkeys, organizations, SSO, admin tooling, API keys and JWTs — implemented entirely with Go's standard library and no third-party dependencies.

According to the project's README, the design is consciously modeled on better-auth, the popular TypeScript authentication framework, and it carries over both that project's scope and its plugin architecture. Setup is a single configuration struct passed to a constructor, and the resulting handler is a plain net/http Handler, so it mounts unchanged on chi, echo, gorilla/mux or gin. The constructor refuses to start on configurations it considers unsafe: a missing or short secret, a relative base URL, SameSite=none without secure cookies, or proxy-header trust declared without a list of trusted proxies.

What's in the box

The core covers email and password authentication using scrypt, with a hash format that stays compatible with better-auth to ease migration between the two. Social login runs over OAuth 2.0 and OIDC with PKCE, with built-in definitions for Google, GitHub, Discord, Facebook, Microsoft, Apple, GitLab, LinkedIn, Spotify, Twitch and X, plus a declarative spec for any other provider. Sessions live in the database with sliding expiration, are carried by signed cookies, and can be listed and revoked through dedicated endpoints; email verification, password reset, account linking, CSRF origin checks and IP-based rate limiting round out the core.

Plugins add two-factor authentication (TOTP, email one-time codes, backup codes), WebAuthn passkeys — including in-tree CBOR/COSE parsing, which keeps the zero-dependency claim intact — magic links, organizations with roles, invitations and teams, domain-matched bring-your-own-OIDC SSO, an admin plugin with bans and user impersonation, hashed and scoped API keys that behave like sessions, EdDSA-signed JWTs with a JWKS endpoint, and bearer-token auth for non-browser clients.

Storage adapters share one conformance suite

Storage ships as adapters: in-memory, SQL through database/sql for PostgreSQL, MySQL and SQLite, and a separate Go module for MongoDB that necessarily depends on the official driver. Every adapter is written against a shared conformance suite that fixes the behaviors the auth core leans on — how unique-constraint violations surface, NULL versus zero values, chronological ordering, clause folding, case-insensitive substring matching and compare-and-set update counts — and third parties can run the same suite against their own adapter.

The README is candid about how far verification goes per backend. SQLite gets the full conformance suite and a complete HTTP auth flow against a real database in CI. PostgreSQL receives the same treatment and, according to the project, already powers a production automation project using the entire feature set. MySQL is exercised against a real MySQL 8 server in CI but has no production track record yet. MongoDB is labelled beta, tested against an internal wire-protocol stand-in rather than a live server. CI sets REQUIRE_DSN=1 so that a missing database fails the tests instead of quietly skipping them.

Engineering posture and the road to 1.0

Each push builds and tests on the oldest supported and current Go releases, runs the race detector, lint, a fuzzing pass over the parsers exposed to untrusted input, and the storage suite against live database servers. The project is pre-1.0: the public API may still change between minor versions, so pinning an exact version is advised. The maintainers list three gates for v1.0 — runnable examples, real-world experience with the newly automated MySQL leg, and a third-party security review — and publish a separate threat-model document.

The proxy configuration trap

Rate limiting and recorded session IPs depend on resolving each client's true address. Behind a load balancer with default settings, every request appears to come from the proxy, collapsing all users into a single rate bucket; with the project's strict default of three sign-in attempts per ten seconds, that effectively becomes a fleet-wide limit. Trusting forwarded headers without restricting which peers may set them fails in the opposite direction: clients pick their own buckets and the limiter stops limiting. The library walks the X-Forwarded-For chain right-to-left past trusted hops only, supports provider-specific headers such as CF-Connecting-IP, and rejects configurations that enable header trust without a proxy allowlist. Direct-to-internet deployments need none of this.

Why it matters

Authentication is the most security-sensitive boilerplate most teams ever write, and Go's options have historically split between framework-coupled solutions and dependency-heavy kits. A standard-library-only implementation shrinks the supply-chain surface and makes audits tractable; the shared conformance suite turns swapping or adding a storage backend into a tested exercise rather than an act of faith; and the honest per-backend verification table is a practice more open-source projects should adopt. The caveats are real — pre-1.0 API churn and no independent security review yet — but with production mileage on PostgreSQL and rigorous CI, it is a release Go developers should watch.