Passkeys for people. OAuth for agents.

One product runs on it in production today — CheckAEO — and CheckAEO is ours. It is first-party, which we would rather say plainly than imply a customer list we don't have; it also means every flow on this page is one we depend on daily rather than a demo.

The whole auth surface went through three adversarial security reviews in August 2026 — run by us, not hired auditors, and written up in full, findings and all. One finding is deliberately still open: an app's existence is discoverable from its subdomain. (Two others tracked at review time have since closed: signing-key rotation shipped, and privileged actions are now recorded internally — the owner-facing view of that record is planned as paid.) The free tier caps you at 3 apps per account.

Requests that are already authenticated keep working. Your server verifies tokens locally against a JWKS it caches, so nothing calls us while your API is serving traffic — if we are slow or offline, your API is not.

What an outage does break is the front door: new sign-ins, consent, and refreshing an expired token all happen here, so nobody new gets in and access tokens drain away as they expire (1 hour). If AuthPop shut down permanently, your users' passkeys would not carry over to a replacement provider — you would point your app at another OAuth provider and your users would enroll a new credential there. We are a small operation; weigh that honestly.

There is no AuthPop SDK and no proprietary token format to unwind. It is standards-based OAuth — PKCE, RFC 8414 discovery, RFC 7591 client registration, ES256 JWTs — so moving to another provider means replacing the authorization-server configuration and re-registering your clients there, not rewriting your application around a different vendor's SDK.

Two honest caveats. A passkey is bound to the domain it was created on — that is what makes it phishing-resistant — so your users' AuthPop passkeys cannot simply be moved to another provider's domain; they would enroll a new credential there. And there is no bulk export endpoint today — in practice your app already holds the list, because every token you accept carries sub and email.

No passwords — none are ever created, so there is nothing to breach, phish, or reset. Email ownership is proven with a 6-digit code before the account exists at all, so nobody can register an address they don't hold, and the token your server receives carries email_verified. Our docs still tell you to key your users off sub rather than email, as defence in depth.

Per user we store an email address, the public half of each passkey (the private half never leaves their device), sign-in timestamps, which OAuth clients they approved, and refresh-token records. No profile data, no analytics on your users. What we do not have yet: SOC 2, a signed DPA, or any other compliance paperwork — if procurement requires those, we are not the right fit today.

First-timers need no explanation: they see the prompt their device already shows for Face ID, Touch ID, or their password manager, and most people never learn the word "passkey". Most passkeys also sync through iCloud Keychain, Google Password Manager, or a password manager, so a new phone usually just works.

When it doesn't — a lost device, or a computer with none of their credentials on it — they enter their email on the sign-in page, get a 6-digit code, and enroll a fresh passkey on the same account; an account can hold several. The tradeoff worth naming: email is the recovery path, so an account is only as strong as its inbox. And there is no owner-side "reset this user" button in the dashboard yet.

Not yet, and we don't have a date to promise.

The subdomain is not cosmetic: a passkey is bound to the exact domain it was created on, which is what stops one app's passkey being usable against another. Custom domains mean per-customer domain verification plus a credential migration path for anyone already enrolled, and we would rather not ship that half-built. Until then, your users see yourapp.authpop.dev on the sign-in and consent screens.

They are far bigger and do far more: enterprise SSO and SAML, organisation and role management, compliance paperwork, support contracts. AuthPop has none of that — if you need any of it, buy one of them instead.

What it does is narrow: one authorization server that handles human passkey sign-in and AI agents (Claude, ChatGPT, Cursor) through the same OAuth flow, MCP-ready by default, with no SDK to install and no passwords anywhere in it.

Nothing is paid today. The free tier is 3 apps per account, 10,000 monthly active users across them, AuthPop branding on the sign-in page, and fair-use rate limits — no card, no trial countdown.

Cross the user limit and we will not lock your existing users out. Sign-ins and tokens keep working; you get a note in the dashboard, creating a new app pauses, and we talk. Throttling real users to prompt an upgrade is a thing we have decided not to do.

A paid tier would eventually cover what the free one deliberately leaves out — your own domain, your own branding, an audit log, more users. What it costs is genuinely undecided, and we would rather say so than print a number we would have to change. Free today is not a promise of free forever; this is standard OAuth, so moving is a configuration change rather than a rewrite.