HSM-anchored · OpenID Connect Core 1.0 · self-hosted

Identity nobody can steal.
Not even the provider.

Every other identity provider holds the secret that proves who you are. This one holds nothing. Your key is generated inside your Encedo HEM and never leaves it — the server assembles the token, your hardware signs it, and the server is left able to verify a signature it cannot produce.

Run your own provider How it works

What the server builds

What your HEM returns

What the server does with it

What the server can sign alone

Four claims, and what backs each one

The server cannot sign for you

The backend builds signing_input — header and claims, exactly as OIDC requires — and hands it to the browser. The HEM signs it. The backend verifies the signature and assembles the token. There is no code path in which it produces one, and no configuration that adds one.

Structural, not a policy setting

A database breach exposes nothing usable

No passwords, no hashes, no session secrets, no MFA seeds, no private keys. What is stored per user is a public key, a device certificate and display claims — public by definition, and useless without the hardware that holds the other half.

Redis only · no SQL, no credential store

No login without the physical device

Every authentication ends at a hardware module that has to answer — approved on your phone or unlocked with a passphrase. A compromised server can refuse a login. It cannot grant one.

Pending session 120 s · auth code 60 s · PKCE S256

Standard OIDC, no cloud dependency

Discovery, JWKS, UserInfo, RP-initiated logout, PKCE — a relying party integrates the way it integrates anything else. Nothing phones home: the only outbound call in normal operation is to your own HEM, on your own network.

Runs air-gapped · Node.js 22 + Redis

In daily internal use at Encedo — Nextcloud (user_oidc), Carbonio CE through the Encedo connector, and GitLab all authenticate against it — and it works the same way with any application that reads discovery. Read the security model →

Your own infrastructure

Three commands. One small VM. No SQL, no cloud.

Do not take our word for any of the above — run the provider yourself. It is one Node.js process with a single dependency, and the whole of its state fits in Redis.

# any small Linux box, Node 22+ and Redis 7+
$ git clone https://github.com/encedo/encedo-oidc.git
$ cd encedo-oidc && npm ci
$ ISSUER=https://auth.example.com npm start

1 process 1 dependency (Redis) 0 secrets at rest Docker multi-tenant template included