YAML
Identity as code
Every user, client, and custom claim is a YAML file you can review, version, and audit like any other code. Changes ship through pull requests, not through an admin panel.
OpenID Connect Identity Provider
Single sign-on for your internal tools, declared as code
Zen IdP is a declarative OpenID Connect provider for small and medium teams. Your users, clients, and claims live in YAML, one root secret drives everything cryptographic, and a single binary handles the rest. No external database, no directory to sync, no passwords to reset.
curl -fsSL https://get.varavel.com/zen-idp | sh
Written in Go, distributed as a single executable and docker image. Free and open source under the MIT license.
What you get
A standard OIDC provider your applications already know how to talk to.
- Self-hosted apps, home labs, and internal tools sign in through OIDC
- Users authenticate with TOTP, no passwords or email involved
- Configuration changes flow through pull requests
See it running
A demo you can start in minutes
Watch the Grafana example end to end: Zen IdP signs the user in,
Grafana accepts the identity, and the whole stack starts with a
single docker compose up.
Why Zen IdP
Built on a few deliberate decisions that keep the whole system small and understandable.
- Root secret
One root secret
A single ZEN_IDP_SECRET derives the OIDC signing key and every user's TOTP credential. Nothing cryptographic is stored in the database, so recovery is deterministic.
- TOTP
TOTP authentication
Users sign in with their identifier and a code from their authenticator app. No passwords to store, no email to deliver, no SMTP to operate.
- PKCE S256
Standard OIDC
Authorization code flow with PKCE, RS256 signing, discovery, JWKS, and /userinfo. Every OIDC-capable application can connect directly.
- SQLite
Disposable state
Sessions, one-use tokens, rate limits, locks, and audit records live in an embedded SQLite file. It holds operational state only: identities and credentials always come from YAML and the root secret.
- MIT
Free and open source
MIT-licensed and fully self-hosted. Zen IdP runs entirely on your own infrastructure, so your identities never depend on a vendor's availability or pricing.
How it works
From YAML to single sign-on
The whole journey is visible. You declare the identity layer, and the service handles the rest.
- Declare identities, clients, and redirect URIs in YAML, split across as many files as you like
- Generate a root secret plus the administrator and client hashes with one command
- Run the binary behind your reverse proxy and hand out one-time enrollment links
- Applications redirect to Zen IdP, users authenticate with TOTP, and everyone gets back to work
Nothing to babysit
Sessions, tokens, rate limits, and cleanup are handled internally, and restarts preserve state. The database is purely operational and never the source of truth.
Use cases
Where Zen IdP fits
A focused identity layer for people who want to own their sign-in.
- Teams
Internal team SSO
One shared sign-in for all the internal tools your team runs itself, with no third-party identity provider in the middle.
- Home labs
Home labs
A single binary with no external services fits on any small server. Declare your users in YAML, run it behind your reverse proxy, and move on.
- Air-gapped
Offline environments
Everything runs locally with no external calls, so Zen IdP works in air-gapped networks where cloud identity providers are not an option.
Small by design
Zen IdP stays focused so you can understand every part of it.
- Binary to run
- 1
- A single Go executable, nothing else to install.
- External services
- 0
- Nothing to install or connect beyond the binary itself.
- CLI commands
- 3
- serve, validate-config, and generate-secrets.
- License
- MIT
- Free, open source, and fully self-hosted.
Common questions
The things people usually ask before adopting Zen IdP.
Zen IdP is a declarative OpenID Connect identity provider. It authenticates your people with TOTP and lets every OIDC-capable application accept those identities through single sign-on. Everything is managed as YAML in your repository, not through an admin panel.
Anyone who wants to own their identity layer. It suits teams that self-host their internal tools and prefer not to depend on a third-party identity provider, home lab owners who want single sign-on across their services, and networks that need an identity provider that works offline. If you manage a handful of tools and want one clean sign-in, Zen IdP is for you.
No. Zen IdP is a single Go binary with an embedded SQLite file that holds disposable operational state: sessions, one-use tokens, rate limits, temporary locks, and short-lived audit records. Identities come from YAML and the root secret, so there is no external database, no LDAP, and no Active Directory to keep in sync.
With an authenticator app. Each user's TOTP secret is derived deterministically from the root secret, so there are no passwords to store and no email to deliver. An administrator creates a one-time enrollment link for each user, and the user scans it into their authenticator once.
Any application that speaks OIDC. Zen IdP implements the authorization code flow with PKCE, RS256 signing, discovery metadata, JWKS, and /userinfo, so the self-hosted tools you already run can connect without custom work.
The way you would expect from a code-first provider: remove or expire the user in YAML and the change applies immediately. For temporary situations, the admin interface can lock a user and revoke all of their sessions at once. Rotating one user's credential is a one-line revision bump in YAML.
Put your identity layer in the repository
Declare your users, choose a root secret, and give your internal tools one shared sign-in. Free, open source, and self-hosted.