Security at Obelisk

Security posture

Obelisk is a security product, and we hold ourselves to the bar we sell. The Gate's own live Obelisk Rating is shown publicly on the homepage, recomputed at most once a minute. Every served page carries a strict, nonce-based Content-Security-Policy, HTTP Strict Transport Security, and modern TLS, with no inline styles or scripts.

This page is the implementation detail. For the plain-language case — why you can trust Obelisk, end to end — see the full trust case →.

Authentication

• Passkey-first / WebAuthn. Credentials are public-key based and the private key is never transmitted to Obelisk or any site: a device-bound passkey stays on its authenticator, and a synced passkey is carried end-to-end encrypted by the platform's password manager. There is no password to phish, reuse, or leak.
• Discoverable (usernameless) sign-in — one tap, no username to type, phishing-resistant by origin binding: the browser offers a passkey only to the site it was made for. The fallbacks — an emailed sign-in link or an authenticator code — are not phishing-resistant, which is why they get a limited session.
• Sessions remember how you signed in. Every session carries a signed record of how it was signed in. A passkey sign-in proves you hold the passkey's private key, which never reaches us. A session from an authenticator code, an emailed link or a remembered 30-day sign-in is limited: it can use your account, but the server refuses it when it tries to add another passkey or remove one, change your authenticator or recovery codes, mint an API key, register an agent, or rename or delete the account, until you sign in with your passkey again.
• Optional TOTP second factor with a pending→confirm setup: until you confirm it, the authenticator isn't accepted for sign-in, and it doesn't stand between you and a passkey sign-in.
• Recovery. A passkey on a second device is the recovery that works on its own. An emailed sign-in link (to a verified address) or a code from an authenticator app you set up gives you a limited session, and a limited session cannot add a passkey to an account that already has one. 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 lose every passkey and your email too, contact us: recovery is case by case and is not guaranteed. If you generate recovery codes, they are shown once and we store only their SHA-256 hashes.
• Federation. Obelisk is an OpenID Connect provider. 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. A SAML sign-on, once connectable, accepts any valid Obelisk session and its assertion does not say how the person signed in.
• Sender-bound tokens — DPoP (RFC 9449). Access tokens can be bound to a client-held P-256 key: the token endpoint accepts a DPoP proof, stamps the key's thumbprint into the token (cnf.jkt), and every protected call must present both the token and a fresh proof signed on-device. Opt-in, per request: an access token can be bound to a client-held P-256 key, and each call then carries a fresh proof signed with that key. A copy of a bound token does not work without that proof wherever the proof is checked: Obelisk checks it where it accepts these tokens, and your own server has to check it too. A token issued without a proof is an ordinary bearer token.

Data protection

• Encryption at rest. The identity database is encrypted with AES-256-GCM. The service is built not to log, display or return secret material, and its tests check for this.
• No user credentials in your app. Your app stores no user credentials: it receives a signed ID token describing the person, not a password, passkey or authenticator secret. 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.
• Tenant isolation. All tenants share one encrypted identity database, kept apart per tenant: no two tenants share a return origin, and no artifact carries secret material.

Tamper-evident audit

Sign-ins, token issuance, grants, console access and account changes are written as hash-chained receipts: each one carries the hash of the one before it, so changing or deleting one changes every hash after it. The latest head of those ledgers is anchored, published and ES256-signed. Here is what you can check yourself, and where those checks stop:

Verify it yourself →

Your own record of the sessions our sign-in paths mint for your account, and of every passkey added or removed, is at /account/issuance. For what that record can and can't show, see what we can and can't do.

What we can — and can't — do

We can't use your passkey. Its private key is never sent to us — it stays on your device, or in your own end-to-end encrypted password manager if it syncs — and we store only the public key, so we can't produce your passkey's signature. Security-sensitive account changes need that passkey.

What we could do, like any identity provider. The service that issues sessions and tokens holds the keys that sign them, so in principle an operator with access to the server could issue a session or token without your passkey. The sessions our sign-in paths mint for your account, and every passkey added or removed, are recorded in a hash-chained log you can read at /account/issuance, naming the passkey behind each passkey sign-in (a sign-in made without one names none), so a sign-in you don't recognise stands out. That log shows what the service recorded. It can't prove nothing was issued outside it, and its writes are best-effort, so a failed write doesn't block a sign-in.

Authenticator codes. If you turn on an authenticator app, its seed is encrypted at rest under a key our service holds, so an operator with server access could in principle read it. That is one reason a code sign-in gets a limited session. Moving these seeds to per-user sealed storage is listed on the roadmap; it isn't done. For the strongest protection, sign in with a passkey.

OWASP Top 10 for agentic applications

How Obelisk's controls line up with the OWASP Top 10 for Agentic Applications (2026). Obelisk is an identity, authorization and evidence layer: it narrows what an agent may do and records what it did. It does not run your agent, so some risks stay with your runtime.

Cryptography & quantum readiness

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). The full inventory of the cryptography in the service's code:

• OIDC tokens — signed ES256 (ECDSA P-256) by default; the JWKS can publish more than one key, so a key can be rotated without breaking tokens already issued.
• Sessions — HMAC-SHA256 macaroons with caveat attenuation, so a session can be narrowed to fewer permissions, never widened.
• Receipts — sensitive actions are written as SHA-256 hash-chained receipts; each ledger's latest hash is anchored into a chain of anchors whose head is ES256-signed (obelisk-sth+jwt) and verifiable against the published JWKS. Per-receipt inclusion proofs (a sparse Merkle tree over SHA-256) are computed on request and aren't yet part of the signed head.
• Refresh tokens — rotating, so a stolen token is detectable on next use.
• Post-quantum — 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; its public key is in the JWKS. Tokens are not post-quantum signed.
• SAML federation — assertions signed RSA-SHA256 with a pinned X.509 certificate — built and tested, though no SAML app can be connected on the hosted Gate yet.

Not listed: a time-lock demonstration in our command-line tooling, built on hand-written arithmetic over a small test modulus. Nothing on the hosted service uses it, and it is not a security control.

Resilience & availability

An encrypted primary store, an immutable break-glass fallback for the operator's own identity, and encrypted backups are designed so the Gate can be restored after a corrupted database, a failed migration, or a misconfiguration; /status says what is measured, including how much recent data a restore could lose. That is the operator's resilience, not a way back into your own account: for that, keep a second passkey on another device.

The disaster-recovery layers, recovery-time targets, and the honest availability caveat all live in one place so they cannot drift: the availability & resilience page →

Vulnerability disclosure

Safe harbor. We will not pursue legal action against good-faith security research that respects this policy: avoids privacy violations, data destruction, and service degradation; tests only accounts you own or have explicit permission to test; and does not access, modify, or exfiltrate other users' data. In scope: obeliskgate.com and the Obelisk identity service. Out of scope: denial-of-service, social engineering, physical attacks, and third-party services we don't operate. A coordinated machine-readable policy is published at /.well-known/security.txt.

The Obelisk Rating

Obelisk continuously scores its own posture across identity strength, the operator's lockout resilience, database integrity, OIDC health, receipt-chain health, threat coverage, and more — each with a confidence weight. Organizations can run the same engine against their own website. See About.