Trust

Security you can prove, not just promise

Most identity providers ask you to take their security on faith. Obelisk is built so you don't have to — every claim below is something you can verify, reproduce, or audit yourself. Here's exactly why Obelisk earns your trust.

The principle: provable, not promised

A promise is a marketing line. A proof is a signature you can check, a credential that physically can't be phished, an audit log that can't be silently rewritten. Obelisk's entire design replaces "trust us" with "verify it." That's the bar — and it's the bar most of the market doesn't clear.

Every pillar below maps to a concrete mechanism, not a policy page. Where it's independently checkable, we tell you how to check it.

1 · Passwordless by default — nothing to phish

Obelisk is passkey-first (WebAuthn/FIDO2). The secret half of your credential is a private key that never leaves your device and is never transmitted — so it can't be phished, guessed, reused, or stolen from a database. Phishing and credential-stuffing, the two most common ways accounts fall, simply don't apply.

Compare the default: most providers still center a password with optional MFA bolted on. Obelisk's default is the phishing-resistant path, with a magic link and recovery codes as backups — never a password to leak.

2 · No secrets to leak — for you or your users

Relying parties on Obelisk hold zero credentials. Your app stores 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. That single architectural choice removes the most damaging class of breach from your surface area entirely. See how it works with your database →

3 · Tamper-evident receipts — an audit that can't lie

Every consequential action — each sign-in, token issued, grant, and access — emits a signed, hash-chained receipt. Because each receipt commits to the one before it, you can't quietly delete or rewrite history: a break in the chain is detectable. This is the heart of "provable." You don't have to trust our logs; you can verify them.

It's the difference between an audit trail you're told exists and one whose integrity is cryptographically enforced.

4 · You can never be locked out

Security that locks out its rightful owner isn't security — it's a hostage situation. Obelisk enforces a never-lockout guarantee with three independent layers: a dual-store resilient backend, a break-glass recovery path, and an encrypted offline backup you control. Losing a device is an inconvenience, never a catastrophe.

5 · Advanced cryptography, no homemade primitives

Obelisk uses standard, audited cryptography via node-native primitives only — no custom crypto:

  • OIDC tokens — signed ES256 (ECDSA P-256) with JWKS key rotation.
  • SessionsHMAC-SHA256 macaroons with caveat attenuation, so every grant is minimally scoped.
  • Receipts — every sensitive action leaves an Ed25519-signed, hash-chained receipt anchored to a Merkle root.
  • Roster non-membership — proven with sparse Merkle inclusion paths.
  • Disaster-recovery secrets — time-locked with a Wesolowski VDF — they cannot be unlocked before a cryptographic delay elapses.
  • Refresh tokens — rotating, so a stolen token is detectable on next use.
  • Post-quantum — an ML-DSA-65 hybrid signature slot is reserved in every receipt chain, ready to dual-sign the moment a stable standard library lands.
  • SAML federation — assertions signed RSA-SHA256 with a pinned X.509 certificate.

Verification is standard OIDC — you can validate every token we issue without trusting our word. Full cryptography reference →

6 · Provable multi-tenant isolation

One shared, encrypted identity plane serves many tenants with isolation enforced per tenant — your organization's data, members, and posture are walled off from everyone else's by construction, not by convention.

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 1,000+ signal points across identity strength, never-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. A provider willing to score itself continuously, visibly, and with receipts is a provider with nothing to hide. 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 · Be the IdP for your whole stack

Obelisk's trust model doesn't stop at your own app — it can be the front door for every tool your team signs in to. Federate Cloudflare, 1Password, and Microsoft Entra over OIDC, and GitHub, Google Workspace, AWS, Slack, Atlassian and more over the SAML 2.0 IdP. Every one of those sign-ins inherits the same passkey-first, assurance-bound, receipt-anchored guarantees — phishing resistance no individual platform can enforce on its own. See the connector catalogue →

10 · Built for the quantum-resistant future

Obelisk is engineered for the quantum-resistant transition: node-native crypto, no exotic primitives to strand, and an ML-DSA-65 hybrid signature slot reserved in every receipt chain — dual-sign activates the moment a stable post-quantum library lands, with zero protocol changes required. Disaster-recovery secrets are additionally gated by a verifiable time-lock (see the cryptography inventory in pillar 5) — a primitive ahead of the market. Your identity layer won't be the thing that's brittle when the cryptographic ground shifts.

11 · Data minimalism

Obelisk stores the minimum required to run secure identity — your identifier, your passkeys' public keys (never the private halves), and the receipt chain. Your application's data stays in your database, under your control. Privacy →