Why Cryden

This page complements Philosophy: philosophy states the principles Cryden holds itself to, and this page walks through the concrete problems that make those principles necessary in the first place.

What Cryden solves

Most teams need authentication before they have time to build it well. The choices that are easy are the ones that cause the damage later: storing passwords with a weak or homemade hash, letting every service keep its own copy of user data, treating a leaked credential as a support incident instead of a detection signal, or handing the whole account system to a hosted provider that owns the users. Cryden is a library that removes those choices by making the secure path the only path.

Auth code gets rewritten for every product

Signup, login, logout, password resets, sessions, email verification, lockout, rate limiting, and audit logs are the same in every codebase, but each team rebuilds them with slightly different bugs. Cryden ships one implementation of all of it, embeddable in any Go application, with no HTTP layer and no framework assumptions, so a CLI tool, an API service, and a web app can all use the same engine.

Hosted auth means the host owns your users

Cryden keeps every user row, session, password hash, and audit event inside your own database. There is no vendor to leave, no proprietary format to escape, no user data crossing your infrastructure, and no telemetry call home. The engine makes no outbound network call on its own initiative, and the few integrations that need one, such as breached-password checking, email delivery, or geolocation, are interfaces you implement and control.

Authentication failures are invisible until they become incidents

Cryden records a typed audit event for every security-relevant action, detects login anomalies and credential-stuffing sprays without blocking legitimate users, rotates refresh tokens and revokes the whole session family when one is replayed, and can summarize a week of that history as a plain-text digest. When a user cannot log in, the support-ticket assistant explains why from the audit trail instead of leaving the team to guess.

Machine credentials get bolted onto human auth and break it

API keys live outside sessions and second factors on purpose, carry host-defined scopes, are stored only as hashes, and fail uniformly for unknown, revoked, expired, or malformed keys, so a stolen key list cannot be probed. Second factors share one pause state, so TOTP, passkeys, and recovery codes never fight each other, and recovery codes cannot become a standalone backdoor.

Doing auth right is a lot of subtle work

Passwords hash with bcrypt or Argon2id with automatic upgrade on login, lockout is persistent and database-backed, email enumeration is blocked by equalized timing, OAuth linking never auto-links on email alone, and access tokens can carry your own claims without letting anyone forge the registered ones. All of it is opt-in through one Config struct, off when unset, and validated at construction time when it matters.

A healthy auth system needs answers for operations and support

The admin layer is read-only by construction: a weekly digest, a login diagnosis, a config tuning report, and an identity-scoped Ask-AI widget all report without any code path that can lock an account, change a setting, or write an event, so a support tool can never make the incident it is investigating worse.

What Cryden is, in one paragraph

Cryden is not a service. It is a library your application imports, a set of plain Postgres or SQLite tables you own, and a coherent set of defaults that make the secure choice the default choice. Teams use it to ship authentication they do not have to rewrite, trust, or hand to someone else.

See Features for the full list of what that adds up to, and Code Examples to see it in practice.