epass

In active development

Sign-in for your apps, without the surveillance.

epass is an identity provider you can run yourself. Passkeys, one-time codes and OAuth 2.1 for every application you build — and an architecture that keeps epass from knowing which of your users are the same person, or how to reach them.

Sign in How the privacy claim works

Self-hosted: one binary and a PostgreSQL database. No agent, no phone-home.

What it does

One authorization server for all of your applications, with the sign-in methods people already have on their devices.

  • Passkeys, first

    WebAuthn sign-in with the platform authenticator people already unlock their device with. Nothing to remember, nothing to phish.

  • OAuth 2.1, properly

    Authorization code with PKCE, the device grant for TVs and CLIs, and token introspection for your own services. Standard clients work unmodified.

  • Codes and links

    One-time codes and magic links over email or Telegram, for the people and the devices that passkeys do not reach yet.

  • Second factors that recover

    TOTP with single-use recovery codes, and lockout after repeated failures — so a lost phone is an inconvenience, not a support ticket you cannot close.

  • Realms, not tenants-in-a-column

    Each realm is its own population of users, its own clients, its own policy. Isolation is enforced in every query, not by a filter someone has to remember.

  • Headless when you need it

    A JSON API for the whole sign-in ceremony, so you can build the screens yourself and still get the security work for free.

We can't lose what we never hold.

That is a statement about how epass is built, not a promise about how it is run. Four properties, each one a thing the code does rather than a policy someone maintains:

Pairwise identities
Every application sees a different identifier for the same person. Two of your apps comparing notes learn nothing, and neither does epass.
Contact details encrypted at rest
Email addresses and phone numbers are stored encrypted. A copy of the database is not a mailing list.
Secrets stored as hashes
Tokens, one-time codes and client secrets exist in the database only as SHA-256 hashes. The plaintext never lands there at all.
Self-hosting as the default
Run it on your own infrastructure against your own PostgreSQL. The strongest proof that a vendor is not harvesting your users is that the vendor is not in the path.

What epass is, and is not

The second list matters as much as the first. epass holds credentials for signing in to your applications — it is not a place to keep your own secrets, and it is not trying to become one.

It is

  • An OAuth 2.1 authorization server
  • A passkey and second-factor registry
  • User management, scoped per realm
  • A device-approval authenticator for your desktop
  • Software you can read, run and keep

It is not

  • A password vault for the rest of your life
  • An autofill extension with access to every site you visit
  • A place to share secrets with other people
  • An analytics product wearing a login page
  • A profile of your users, assembled across your apps

Built on the standards, not beside them

Nothing here is a proprietary handshake. If your client library speaks these, it speaks epass.

  • OAuth 2.1
  • PKCE · RFC 7636
  • Device Authorization Grant · RFC 8628
  • Token Introspection · RFC 7662
  • WebAuthn · FIDO2
  • TOTP · RFC 6238