H2 Labs
← What we build and run

Identity Core · single sign-on

Sign in with your key.
No password to steal.

Identity Core is the single sign-on we wrote from scratch in Rust. People sign in with a passkey or a security key: to web applications through OpenID Connect, and to Fedora Linux at the login and lock screens. Sudo rules name the exact command. It runs our own sign-in at id.h2.io.

How it works See it live at id.h2.io

One identity for apps, Linux and sudo

Each person has one account, held by Identity Core. Applications ask it who is signing in, and Linux machines take from it who may log in and what each person may run. Disable someone, and their sessions and open invitations are revoked at once; a machine working offline learns of it when it reconnects or its lease runs out.

Fig. 1 One key and one account for apps, Linux and sudo

Applications. Web applications sign in through OpenID Connect. Before an application learns who the person is, Identity Core asks for their consent and names the application; the organisation’s own applications can be set to skip that screen.

Linux. The security key opens the login screen and the lock screen with its PIN and a touch. A laptop keeps working offline for a set time, under a signed lease.

Sudo. Each rule names the exact command, its arguments and the account it runs as, and every command is checked again when it runs.

Accounts without a password

Identity Core holds no password to steal, phish or reset: neither the server nor its pages handle one. People sign in with a passkey or a security key, and a key’s PIN goes into the browser’s own prompt, which the page cannot read.

Table 1 An account, from the invitation to a lost key.

  1. 01 / invite

    By invitation only

    An administrator issues an enrolment token. It works once, expires after 15 minutes and is stored only as a hash.

  2. 02 / sign in

    A key, then a session

    The person enrols a passkey or a security key and signs in with it. On id.h2.io a sign-in lasts a fixed 8 hours, and extending it asks for a fresh touch.

  3. 03 / keys

    Several keys each

    People name their keys, add a spare and remove a lost one. Changes need a touch of a key already on the account, which can unlock key changes for five minutes, and the last key cannot be removed.

  4. 04 / recover

    Every key lost

    An administrator recovers the account. All the old keys and server sessions are revoked, and the account keeps its permissions.

  5. 05 / leave

    Someone leaves

    Disabling a person revokes their server sessions and their open invitations at once.

  6. 06 / admin

    Changes need a key

    The admin pages change nothing until an administrator verifies with a key, which opens a five-minute window. Successful enrolments, sign-ins and identity changes are recorded.

Failure logs without secrets. A failed attempt shows the person a reference they can quote. The failure log holds only fixed fields and that reference: never credentials, tokens, cookies, usernames or request bodies.

Sign-in for your applications

Applications sign in through OpenID Connect. Identity Core supports a deliberately narrow profile: the authorisation code flow with PKCE for people, exact redirects, and refresh tokens that rotate.

What an application gets

  • Code flow with PKCEThe authorisation code flow, with S256 PKCE only. Redirects must match the registered address exactly. ID tokens are signed (RS256), and discovery, signing keys and UserInfo are published.
  • ConsentIdentity Core names the application and the account, and the person chooses “Allow and continue” before the application learns anything. The organisation’s own applications can be set to skip this screen.
  • Refresh tokens that rotateRefresh is switched on per application. Every refresh returns a new token, and replaying an old one revokes the whole family. A family lasts at most an hour, ends after 15 minutes without use, and never outlives the sign-in.
  • Tools and servicesCommand-line and headless tools sign in with the device flow, approved in a browser. A service gets a token for one named API and scope with client credentials, and never becomes a person.
  • Logout and revocationApplications that register a logout address get a signed back-channel message when a session ends, retried for up to an hour. Access and refresh tokens can be revoked, and an API can look up the service tokens it receives.
  • Several accountsIdentity Core holds up to eight accounts in one browser, chosen per tab, and one account never silently becomes another. An application keeps accounts apart per tab only if it supports this itself.

An existing company sign-in can stay. Identity Core accepts sign-ins from OpenID Connect issuers an administrator names. An administrator links each person, or the person links themselves with a key touch and a fresh sign-in upstream. Upstream usernames and roles never become local accounts or rights. We have tested it with one outside product, Keycloak 26.7.2, as the company issuer, passkeys at Keycloak included (26 of 26 checks, 5 October 2026). Identity Core sees that the company sign-in happened, though it cannot see how the person proved who they were.

Linux, with rights granted one by one

Each machine enrols with its own key and receives a signed policy: who may log in, which way, and which commands they may run as whom. Logging in, working offline and using sudo are separate grants: a login grant includes neither offline use nor sudo.

Fig. 2 One key, one machine, three separate grants

Identities in one place. User and group IDs are set centrally and stay the same on every machine. An existing local account can be linked in place and keeps its IDs, groups, home and files. Matching usernames alone never link anything.

A signed policy. Each machine’s policy is signed with Ed25519. Before installing it, the machine checks the signature, that the policy names this machine, its expiry and its sequence.

A lost machine. One step revokes the old machine and invites a clean replacement, and access to it is restored explicitly.

Table 2 Four ways onto a machine, each its own grant.

  1. 01 / console

    Console, approved in a browser

    The terminal shows a sign-in link, and the person approves it in a browser, so the key can stay on another device.

  2. 02 / desktop

    Login and lock screen

    The security key’s PIN and a touch, at the graphical login and at the lock screen, with no browser involved. If access is revoked while the screen is locked, it stays locked. Login and the lock screen are tested with LightDM and Xfce on Fedora 44; login with GDM on Fedora Silverblue was confirmed by hand.

  3. 03 / offline

    Offline, for a set time

    Login without a network for a set time, under a signed lease that counts from the last successful refresh. A rejection from the server ends it. A machine without a network learns of a revocation when it reconnects, or when the lease runs out. Keeping the lease across a reboot, and sudo while offline, are each a separate opt-in.

  4. 04 / sudo

    Sudo, by exact command

    Each rule names the executable, its arguments and the target user. One touch can cover five minutes in the same terminal, and the permission is checked again on every command. A refused command never falls back to the local sudoers file, and sudo -l lists the rules.

Installers that keep a way back. The installers for Fedora 44 and Fedora Silverblue keep root and the local administrator’s normal login working. Uninstalling puts back the original PAM and sudoers files byte for byte, and every package is signed.

We run it ourselves

Our own sign-in at id.h2.io is Identity Core. It signs our team in to our web applications and to our Linux machines, from three servers, any two of which commit each change.

Fig. 3 Any two of the three members commit each change

One file, or three members. By default Identity Core is one program and one database file on your server. For sign-in that keeps answering with a server stopped, it runs as three members on three of your machines.

Two of three agree. Any two members can commit a change. A member on its own cannot sign anyone in from an old copy, and no cookie, token or signed policy goes out until the majority has accepted the change.

The test. At launch on 7 October 2026 we stopped each of the three members in turn, behind our one public entry point, and the public sign-in and its discovery document kept answering. All ten launch checks passed.

Upgrades and backups. Compatible upgrades roll through one member at a time, from signed release manifests. In the one-file setup, backups are taken while the server runs and checked for integrity. They leave out sessions and pending invitations, always restore to a new place, and are not encrypted, so they need the same care as the database.

Built small, on purpose

One server program, built on well-known libraries, with each key kept to one job.

One server program

Written in Rust on Axum and Tokio, with SQLite compiled in and rustls for TLS. Passkeys go through webauthn-rs, and there is no home-made cryptography.

Plain pages

The sign-in and admin pages are plain HTML, CSS and JavaScript inside the program. There is no framework and no CDN, and no Node or Java at run time.

One key per job

Releases, TLS, machine policies, each machine and OpenID Connect signing each have their own key, with its own rotation and recovery procedure.

Strict at the edge

The pages at id.h2.io carry a strict content security policy, refuse framing and caching, and send no referrer. Cookies carry the __Host- prefix.

What is tested, and how

All of it is our own testing. The automated tests use virtual or software keys in browsers, containers and virtual machines. Physical security keys were used by hand on our team’s machines.

114automated tests in the main code base, all passing when run on 4 November 2026
25areas, each with its latest recorded test report passing in full, 5–12 October 2026
1,298checks in those reports, all of them passed
Table 3 The latest recorded test report in each area, all from October 2026.
What the report coversChecksDateKeys
Sign-in and applications
Passkeys in the browser: enrol, sign in, replay, origin, restart, backup and restore44/445 Octvirtual
OpenID Connect with a separate application92/9212 Octvirtual
Refresh, revocation, logout and the device flow127/12712 Octvirtual
Confidential clients and service tokens78/787 Octvirtual
Company sign-in between two Identity Core issuers56/5612 Octvirtual
Company sign-in from Keycloak 26.7.226/265 Octvirtual
Keys and accounts
Naming, adding and removing keys38/385 Octvirtual
Recovery after every key is lost34/3412 Octvirtual
Rate limits and caps on pending sign-ins20/206 Octnone
Linux
Console login in a virtual machine, approved in a browser31/315 Octsoftware
Graphical login and lock screen, Fedora 44 with LightDM and Xfce29/295 Octsoftware
Machine enrolment and signed policy, two machines73/735 Octsoftware
Sudo by exact command, two machines38/385 Octvirtual
Offline login37/375 Octsoftware
Offline login across a reboot63/635 Octsoftware
Sudo while offline28/285 Octsoftware
Replacing a lost machine52/525 Octsoftware
The Fedora 44 installer, from install to uninstall110/1106 Octnone
The Fedora Silverblue package, from install to uninstall101/1016 Octnone
Running it
Real HTTPS, and moving the service between machines54/545 Octsoftware
Recovery from a compromised policy key48/485 Octsoftware
Recovery of the OpenID Connect signing key46/467 Octsoftware
Signed release bundles30/305 Octnone
Three members, any two committing each change33/336 Octnone
Launch checks at id.h2.io, each member stopped in turn10/107 Octnone

Keys: virtual is a browser’s built-in test authenticator, software a security key emulated in software, and none a test that needs no key.

Confirmed by hand, with physical keys

  • A Nitrokey 3, in a containerOn 5 October 2026: offline login with a Nitrokey 3 in a container. Its PIN retry counter read 8 before and after.
  • Offline across a rebootOn 6 October 2026: graphical login with a security key, offline, before and after a reboot. The key’s PIN retry counter read 8 before and after.
  • A key at id.h2.ioOn 7 October 2026: one security key enrolled by hand and used to sign in to the live service.
  • Login and sudoOn 7 October 2026: graphical login and sudo on a team machine after it moved to id.h2.io.
  • A second desktopOn 9 October 2026: login at a username greeter, and offline login, on another team machine with a different desktop.

Talk to us about your sign-in

Identity Core runs our own sign-in today: our team, our web applications and our Linux machines, at id.h2.io. Tell us what your people sign in to, and we go through it with you, part by part.

Talk to us What we build and run
  1. KeysPasskeys and security keys. No passwords, accounts by invitation, spare keys and recovery.
  2. AppsOpenID Connect. Consent, PKCE, refresh tokens that rotate, and back-channel logout.
  3. LinuxFedora 44 and Silverblue. Login and lock screen by key, offline leases and exact sudo rules.
  4. ServersYours. One program and one database file, or three members, any two of which commit each change.