Compare

Obelisk vs the field

How does Obelisk compare to Clerk, Auth0, WorkOS, Stytch, Okta, Microsoft Entra Agent ID, Descope and Keycard? Each of those is a strong product for its audience. Obelisk takes a different stance: passkey-first by default, an audit trail you can check yourself, and a live security score the Gate publishes about itself. Pick a head-to-head below.

The field at a glance

Identity is crowded, and most providers are genuinely good at what they target. We're not here to pretend otherwise — each deep-dive gives the competitor real credit for what it does best. What sets Obelisk apart is consistent: it makes the login the part of your stack you can verify, not just trust.

Head-to-headThey're known forDeep-dive
Obelisk vs Clerk Drop-in React/Next.js auth components Read the deep-dive →
Obelisk vs Auth0 Incumbent, flexible enterprise IAM platform Read the deep-dive →
Obelisk vs WorkOS Enterprise SSO/SCIM for B2B SaaS Read the deep-dive →
Obelisk vs Stytch API-first passwordless & fraud-prevention Read the deep-dive →
Obelisk vs Okta Incumbent enterprise IAM / workforce identity Read the deep-dive →
Obelisk vs Microsoft Entra Agent ID Agent identities inside Microsoft Entra Read the deep-dive →
Obelisk vs Descope Customer and agentic identity platform Read the deep-dive →
Obelisk vs Keycard Runtime authorization for agents Read the deep-dive →

What Obelisk brings

These capabilities recur across the comparisons. Some providers have some of them too; each deep-dive says how that provider compares, and its agent rows link the vendor page they come from.

  • Passkey-first by default
  • A live, public security score for the provider itself
  • Verifiable seal embed
  • Tamper-evident hash-chained receipts
  • OpenID Connect provider
  • Per-sign-in pricing, with every billed sign-in recorded as a receipt you can check
  • Agent records with opt-in public Proof Links
  • Third-party check of agent authorization
  • Self-operated root-of-trust

How each provider compares, side by side: Clerk · Auth0 · WorkOS · Stytch · Okta · Microsoft Entra Agent ID · Descope · Keycard.

The throughline: passkey-first by default, tamper-evident receipts you can check, and the Obelisk Rating, a live, public security score for the Gate itself. See the full trust case →

The Obelisk difference, in one list

Every head-to-head comes back to these. Each one says what runs today, including what is built but not yet switched on:

  • Passkey-first by default. Passwordless via WebAuthn/FIDO2 is the default path, not an add-on. The secret half of a passkey is never sent to Obelisk or to the site, so there is no password to stuff and no passkey secret in our database to steal, and the browser offers a passkey only to the site it was made for, which is what makes it phishing-resistant. The fallbacks, an emailed link or an authenticator code, can be phished like anywhere else, so they only get a limited session.
  • A live, public security score for the Gate itself. The Obelisk Rating is the Gate's own security, scored 0–100 from hundreds of live signal points and shown on its homepage. It rates the Gate, not your app or your sign-in page.
  • The verified seal embed. A drop-in login card (obeliskgate.com/embed/seal.js) that shows its ✓ only on an address your registration names and links to a verification page at obeliskgate.com listing your registered addresses and what Obelisk Gate measured about your registration, each with when it was measured.
  • An OpenID Connect provider. Obelisk is an OpenID Connect provider: tools that accept an outside OIDC identity provider can use it for sign-in, and each ID token's obelisk.assurance claim says how the person signed in, so a tool that reads it can require a passkey. 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.
  • Tamper-evident, hash-chained receipts. Sign-ins, tokens and grants are written as hash-chained receipts, anchored under an ES256-signed ledger head you can check against our published JWKS. Save the head and its anchor count: a later count that went down, or a different head at the same count, shows the record was cut short or replaced. Consistency proofs between heads aren't published yet.
  • Sender-bound tokens (DPoP, RFC 9449). 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.
  • Sensitive changes need a passkey. What a session may do follows how it was signed in. A remembered 30-day session, an authenticator code or an email link gets you in, but adding another passkey or removing one, changing your authenticator or recovery codes, minting API keys, registering agents, and renaming or deleting the account are all refused from any of them until you sign in with your passkey again. The risk score on your account page is an advisory read: it does not allow, block or step up any sign-in.
  • Off-box disaster recovery. Disaster recovery is built on encrypted off-box backups with a recovery-time objective of ~15 minutes (a target; the status page shows what is measured). For a lost device, a backup passkey on a second device is the recovery that works on its own.
  • Per-sign-in pricing. Every billed sign-in is recorded as a receipt you can check. It is not the cheapest option for sign-in alone; see /pricing.

The agent era, honestly

Okta, Microsoft Entra Agent ID, Descope and Keycard each give agents an identity of their own; each head-to-head draws its agent rows from the vendor's own page and links it. Here is where Obelisk stands.

  • What Obelisk does. Each agent is its own record in Agent Studio: its own key, held by the agent's runtime (Obelisk never receives the private key), a passkey-holding owner, and an opt-in public Proof Link that is opaque and revocable. Agents are registered, scoped and revoked in Agent Studio.
  • Where it differs. Registering, approving, transferring or revoking an agent writes a receipt to Obelisk's hash-chained ledger. Anyone holding a receipt's hash can fetch its position in the chain and a Merkle inclusion proof at /api/proof/<hash>, with no account.
  • What it does not do yet. No OAuth grant issues an access token to an agent on its own: the token endpoint grants only authorization_code and refresh_token. There is no client-credentials, token-exchange or ID-JAG grant. Every ID token carries an obelisk.principal claim, and its type is always human: an ID token comes only from a person's sign-in.
  • A self-operated root-of-trust. Obelisk is built and run end-to-end by one accountable studio that runs Obelisk on Obelisk, passkey-first and usernameless by default. You're trusting a root you can watch: one studio builds and runs it, and publishes a live Rating on itself.

Wiring tools instead of a web app? Integrate Obelisk or protect an MCP server with MCP authorization.

Jump to a head-to-head

Give your users a login that keeps receipts.

Passkey sign-in, OAuth for agents, and a record anyone can check.

Create your account →Verify it yourself →

Already have an account? Sign in.