Obelisk · Integrate Obelisk

The mental model

Obelisk owns authentication — proving who a user is. Your app keeps owning your data — everything that user does. The two meet at one stable value: the user's Obelisk subject id (sub). You never see or store passwords; Obelisk never touches your database.

One line to remember: Obelisk hands you a signed, verified identity. You map that identity to a row in your own database. That's the whole integration.

Obelisk handles: passkeys (WebAuthn), magic links, TOTP step-up, recovery codes, rate-limiting, lockout protection, the audit trail.
You handle: your application data, your authorization rules, your UX after login.
The bridge: a verified ID token (or a server-to-server session check) carrying the user's sub.

How it works with your own database

This is the part teams ask about most. Obelisk is not a database for your app — it's the gate in front of it. You keep your existing users table; you just stop storing credentials in it.

Before Obelisk, a typical users table holds email, password_hash, mfa_secret, reset_token… all of it sensitive, all of it your liability.

With Obelisk, you drop every credential column and add one:

Column	Holds	Source
`obelisk_sub`	The stable subject id for this user	Obelisk ID token (`sub` claim)
`email`, `name`, …	Profile (optional, cached)	Obelisk claims, or your own forms
your app columns	Whatever your product needs	You

On a user's first sign-in, you just-in-time provision: look up obelisk_sub; if it's new, insert a row. On every later sign-in, you find the existing row by obelisk_sub. The sub is stable and opaque — it never changes, even if the user changes their email.

Zero credential storage. No password hashes, no MFA secrets, no reset tokens in your database — so they can't leak from your database. That single change removes the most common and most damaging class of breach from your surface area.

Your data stays yours, in your database, under your control. Obelisk only ever answers one question: "is this the user they claim to be?"

Quickstart — standard OIDC

Obelisk is a standards-compliant OpenID Connect provider, so any OIDC client library works. Discovery lives at /.well-known/openid-configuration; keys at the JWKS endpoint it points to.

Register your app to get a client_id and your redirect URI allow-listed.
Send the user to /authorize with PKCE (response_type=code, your state + code_challenge).
Exchange the code at /token for an ID token + access token (+ rotating refresh token).
Verify the ID token against the JWKS (ES256). The verified sub is your user key.
Create your own session and look up / provision the user by sub.

Standard libraries (e.g. an OIDC client for your language) handle steps 2–4; you write step 5 against your database. PKCE is required; refresh-token rotation is on by default.

Watch it end to end

Six steps, and you only write the last one. Press play, or click any step — the payload shows what's actually moving.

Obelisk owns steps 1–5. You only write step 6.

The thin-RP pattern — zero project secrets

If you don't want to run a full OIDC client at all, Obelisk supports an even lighter pattern: your project is a thin relying party that holds no secrets. After login, you verify the session server-to-server against Obelisk (/auth/verify-session) and trust the verified identity it returns. Ideal for internal tools and small services where one shared login is the goal.

Choose OIDC when you want standards + access tokens for APIs. Choose the thin-RP pattern when you just want "one secure login, no secrets to manage."

Drop in the verified seal

Want the fastest possible proof on your login page? Paste one script tag and Obelisk renders a “Secured by Obelisk Gate” login card — served live from obeliskgate.com inside a framed card, so it can't be forged, auto-updates itself, and shows your site's live Obelisk Rating with a ✓ that links to your verified relying-party page.

<script src="https://obeliskgate.com/embed/seal.js" async></script>

Full setup, framework snippets, and the verification model live in Add the Obelisk Gate seal.

Or be the IdP for your whole stack

Obelisk isn't only OIDC. It's a full OpenID Connect provider and a SAML 2.0 IdP (RSA-SHA256-signed, cert-pinned assertions), so beyond your own app it can be the passkey-first front door for the tools your team already uses — Cloudflare, 1Password, and Microsoft Entra over OIDC, and GitHub, Google Workspace, AWS, Slack, Atlassian and more over the SAML 2.0 IdP. Browse the connector catalogue →

Verifying tokens

Tokens are signed ES256 (elliptic-curve, node-native crypto — no custom primitives). Verify them the standard way: fetch the JWKS, match the kid, check signature, iss, aud (your client_id), and expiry. Keys rotate; cache the JWKS and refetch on an unknown kid. Refresh tokens rotate on every use, so a stolen refresh token is detectable.

Sender-bound tokens (DPoP). For agent and server workloads where a token might ride in logs, env vars, or long-lived memory, opt in to DPoP (RFC 9449): send a DPoP proof header at the token endpoint and Obelisk binds the access token to your client-held P-256 key (cnf.jkt). Every protected call then requires both the token and a fresh proof signed with that key — a stolen token without the key is inert. The plain bearer flow is untouched; DPoP is opt-in per request.

What you never have to build again

Password storage, hashing, and breach monitoring — gone.
Passkey / WebAuthn ceremonies, including the orphan-credential edge cases — handled.
MFA, step-up, and recovery flows — handled.
Rate-limiting, lockout, and abuse protection on the auth path — handled.
A tamper-evident audit of every login and token — built in (receipts).

You ship your product; Obelisk is the front door. See the machine-readable API manifest for endpoints, and Security for the trust model.