The principle: provable, not promised
A promise is a marketing line. A proof is something you can check yourself: a signature against our published keys, a passkey your browser offers only to the site it was made for, an audit log whose signed head you can save and compare later. Obelisk is built so that more of its claims are the second kind, and where a check has limits, we say what they are.
Most pillars below map to a mechanism you can check; we say which ones you can't.
1 · Passwordless by default, with phishing-resistant passkeys
Obelisk is passkey-first (WebAuthn/FIDO2). The secret half of your passkey is a private key that is never sent to Obelisk or to any site — it stays on your device, or a synced passkey is carried end-to-end encrypted by your own password manager — so there is no password to guess or reuse, and no passkey secret in our database to steal.
A passkey is phishing-resistant: your browser offers it only to the site it was made for, so a look-alike sign-in page can't collect it, and there is no password for credential stuffing. The fallbacks — an emailed sign-in link or an authenticator code — can be phished like anywhere else, which is why they only get a limited session that can't add another passkey or remove one. The backup that works on its own is a second passkey on another device (see pillar 4).
2 · No user credentials in your app
Your app stores no user credentials: no password hashes, no MFA seeds, no reset tokens — because Obelisk handles authentication and hands you a verified identity. You can't lose what you don't store. A public (PKCE) client holds no client secret at all; a confidential client holds one client secret, shown to you once, of which Obelisk keeps only a SHA-256 hash. See how it works with your database →
3 · Tamper-evident receipts you can check
Sign-ins, tokens, grants and account changes are written as hash-chained receipts. Each receipt carries the hash of the one before it, so changing or deleting one changes every hash after it. The ledger's latest head is anchored and published with an ES256 signature you can check against our published keys. You can also fetch a Merkle inclusion proof for any single receipt; its root is computed when you ask and is not yet part of the signed head.
What you can check today, without an account
- Save the signed ledger head, and compare it later. Fetch
/.well-known/obelisk-transparency.jsonand keep itsheadAnchorHashandanchorCount. On any later fetch the count must never go down, and while the count is the one you saved, the head must not change. A break in either rule is evidence the record was cut short or replaced. - Check that the head was signed with our key. The document's
sthfield is an ES256 signature over the head. Verify it against our published keys at/.well-known/jwks.json; the head check on the Verify it yourself page does this in your browser. - Check that a receipt you hold is in the ledger. Paste its hash into the receipt check on the Verify it yourself page. Your browser recomputes the Merkle proof from
/api/proof/<hash>, and a match shows the receipt is in the ledger we serve today. The check searches the receipts ledger; sign-in records are kept in a separate ledger it doesn't search. - Check a token we issued. Verify an ID or access token's ES256 signature with any JWT library against
/.well-known/jwks.json. Once you have the keys, that check needs nothing more from us.
What those checks can't show yet
- That a later head extends the one you saved. We don't publish consistency proofs between heads, and we don't serve past heads, so comparing heads catches a history that was cut short or replaced, not one that was rewritten and then extended with new entries.
- That a receipt check is covered by the signature. The root a receipt proof is checked against is computed by us when you ask and arrives in the same response. It isn't part of the signed head yet.
- That our keys and our records are honest. You fetch the signed head and the keys that verify it from us, so a valid signature shows the head was signed with the key we publish, not that what it describes is complete.
- That nothing happened without a record. The ledgers show what the service recorded, not what it didn't. Sign-in records are written on a best-effort basis, so a failed write doesn't block a sign-in.
- That someone outside holds the same head. Whether an outside copy of the head is verified is shown live on the status page. While none is, the copy you save is the outside record.
Don't take our word for it: Verify it yourself →
4 · Plan for a lost device
Security that locks out its rightful owner isn't security, so Obelisk says plainly what gets you back in. A second passkey on another device is the recovery that works on its own: sign in with it, add a passkey for your new device, and remove the lost one.
An emailed sign-in link to a verified address, or a code from an authenticator app you set up, gives you a limited session. A limited session cannot add a passkey to an account that still has one registered, so it reaches your account but does not finish a recovery by itself. Lost the only device with your passkey? A one-time recovery code created after signing in with a passkey, or an email recovery to your verified address that opens only after a 72-hour hold, with a link to cancel it, lets you add a new passkey and nothing else. If you have lost every passkey and your email too, contact us: recovery beyond these paths is case by case and is not guaranteed.
5 · Standard cryptography, nothing home-made
We don't invent cryptography: every signature, hash and cipher the service's code computes is a standard, published algorithm, run by Node.js's built-in crypto library or by two open-source libraries (@simplewebauthn/server checks passkey signatures, and xml-crypto handles SAML's XML signatures). In practice that means ES256 signatures, SHA-256 hash chains, HMAC-SHA256 sessions, AES-256-GCM encryption at rest, and WebAuthn passkeys. Tokens are standard OpenID Connect, so you can validate any token we issue against our published keys with an ordinary JWT library.
The full inventory — every algorithm, where it's used, and why — lives on one page so it can't drift: the cryptography reference →
6 · Per-tenant isolation
One shared, encrypted identity service serves many tenants. Every registered app belongs to exactly one tenant — a personal account, an organization, or our studio's own tenant — and sign-ins are counted and billed per tenant. An organization's own figures are shown only to its owners and admins. A check that runs in our CI refuses any client in our committed app registry that claims our studio's tenant or reuses one of its client ids. You can't check this from outside; it is a statement about our code.
7 · We measure our own posture — in public
Obelisk runs the Obelisk Rating on itself: a live 0–100 score (with decimal precision) distilled from hundreds of signal points across identity strength, the operator's lockout resilience, database integrity, OIDC health, receipt-chain health, assurance enforcement, and threat coverage — each with a confidence weight, a grade, and a trend. The Living Fortress mark renders it in real time: the ring's hue is your security band, its lit segments are your coverage — the circle closes as you're protected. Run the same engine on your own website from the homepage. The score is self-measured; the coverage figure shows how much it actually measured. See the live demo →
8 · Transparency & responsible disclosure
Obelisk publishes a machine-readable API manifest, an RFC 9116 security.txt with a clear vulnerability-reporting channel, and a safe-harbor commitment for good-faith researchers. Found something? We want to hear it. Security & disclosure →
9 · One sign-in for your team's tools
Obelisk's trust model doesn't stop at your own app: it can be the sign-in for the tools your team uses. Cloudflare, 1Password, and Microsoft Entra can use Obelisk as their OpenID Connect sign-in. Each ID token's obelisk.assurance claim says how the person signed in, so a tool that reads it can require a passkey. SAML apps such as GitHub, Google Workspace, AWS, Slack, and Atlassian can't be connected on the hosted Gate yet. See the connector catalogue →
10 · Post-quantum signatures on the tree head
An ML-DSA-65 signer (RFC 9964, FIPS 204) adds a second signature to the transparency tree head beside ES256, in a separate field, so existing verifiers are unaffected, and its public key is in the JWKS. Sign-in tokens are not post-quantum signed. Our release check verifies the live post-quantum signature before a release, and confirms that a head whose content was changed after signing is refused.
11 · Data minimalism
Obelisk stores what it needs to run sign-in — your identifier, your email if you give one, your passkeys' public keys (never the private halves), your authenticator secret (encrypted) and recovery-code hashes if you set them up, session and device records, and the receipt chain. Your application's data stays in your database, under your control. Privacy →
Ready to build on it? Integrate Obelisk · See pricing · Create your account.
What we don't have yet
A page that only lists strengths is the thing this one argues against. So, plainly, what Obelisk does not have today: SAML connections, SOC 2 or ISO 27001, an external penetration test, a paid bug bounty, and an uptime SLA. If any of these is a requirement for you, it is better found here than in procurement.
- SAML apps can't be connected. A SAML 2.0 identity provider is built, with published metadata and RSA-signed assertions, but SAML apps can't be connected on the hosted Gate yet. OpenID Connect is the path that works today.
- No SOC 2 or ISO 27001. We hold no third-party compliance certification. What we publish instead is the evidence itself: a signed ledger head and receipts anyone can check without an account.
- No external penetration test. No independent security firm has tested the Gate. Our own gates, tests and the public Rating are self-measured, and the site says so wherever it shows them.
- No paid bug bounty. There is no reward programme. Disclosure is still welcome and answered — security@obeliskgate.com, and a machine-readable policy at /.well-known/security.txt.
- One server, no uptime SLA. The Gate runs on a single host with off-box backups and a published recovery objective. There is no multi-region redundancy and we offer no uptime guarantee; /status carries the current limits.
Need one of these for your team? Tell us which one — it is the most useful thing you can send us, and it is how this list gets shorter.