Your login page.
Your domain.
Never billed
per user.
Every other auth vendor's price goes up when your app starts working. Ours cannot, because auth is not what we sell. Monthly active users are metered and never billed — at every size.
14-day free trial on your first subscription · card collected at checkout · cancel any time
Shapes, not quotes — no rival's numbers appear on this chart. Note where the other line starts: below ours. A vendor priced per monthly active user is usually cheaper than us while you are small, and several are free at your first few thousand users. We draw it that way because it is true, and because it is the whole point — nobody leaves an auth vendor while they are small. What we can promise is the other line: any bill computed from your monthly active users rises when your product works, and ours cannot, because monthly active users are metered and never billed, full stop. Check theirs yourself — clerk.com/pricing · supabase.com/pricing · auth0.com/pricing.
Success is when the bill detonates.
Nobody churns off an auth vendor while they are small. They churn later, once the invoice has quietly grown a second page — and by then leaving means asking every user you have to reset a password nobody can export. That is not a pricing accident. It is what happens when a vendor's revenue is computed from your user count. Ours is not.
No vendor named and no figure invented — these are line-item shapes, not quotes. Read any per-user identity vendor's own pricing page and you will find some arrangement of them. The point is not how large the number is. The point is that it is a number which grows when your product does.
And then it stops. There is no organizations line, no impersonation line, no per-connection line and no retained-user line, because monthly active users are metered and never billed. The next row on this invoice is blank at 500 users and blank at 500,000.
We don't sell auth.
Auth cannot be our growth lever, because it is not our product. Parsons is a platform of twenty-two services on one subscription, and identity is the part that has to exist before any of the others make sense. So we built it, we meter it, and we stopped there.
Auth is not highlighted in that list, and that is the point. It is one chip among twenty-two, at the same weight as the rest — not a line item, because it is not a product here. It is plumbing that comes with the account.
The redirect that never happens.
Most auth products move your user to a host they control, take the credentials there, and bounce them back. Ours never enters the address bar. Your login form posts to your backend; your backend calls /v2/authenticate with its secret key and gets tokens straight back in the response body.
There is no hosted sign-in page of ours to brand, because we removed ours on 2026-08-02. There is nothing to charge you for taking our name off. The door is yours.
Which also means you build the login form. It is four POSTs, and we would rather say so here than have you discover it in the docs.
Four calls, no SDK.
There is nothing to learn and nothing to install. It is one JSON API on your project's sk_live_ key: sign up, authenticate, refresh, revoke. Password, Google, Apple and magic link are endpoints on that same plane, each togglable per project — a disabled method answers method_disabled rather than quietly working.
user_metadata / app_metadata — 4 KiB each, merged server-side
/v1/users is still live and is not deprecated
Read the API reference →
Another tenant's valid id is a 404, not a disclosure.
One worker serves every tenant, so isolation cannot be a WHERE clause somebody remembers to write. It is a uniqueness constraint that has been in the schema since line one, and a data-access layer that binds project_id into every query it builds.
| project_id | id | created | |
|---|---|---|---|
| proj_9f4c2ab1e8d3 | ada@yourapp.com | usr_4f1c | 2026-08-04 |
| proj_1b77e0d5c9a2 | ada@yourapp.com | usr_a0e8 | 2026-08-11 |
| proj_9f4c2ab1e8d3 | grace@yourapp.com | usr_77b2 | 2026-08-14 |
| proj_1b77e0d5c9a2 | hopper@other.dev | usr_c31d | 2026-08-19 |
The row is still on screen. It exists, it is valid, and you are holding a valid key — for a different project. The record does not disappear from the database; it disappears from your reachable universe. Same email, two tenants, no collision, no leak.
The rung, and the parameters.
"Securely hashed" is worth nothing — everyone says it. Here are the actual numbers, the actual timings, and the one place we deliberately chose availability over strictness and will tell you why.
N=2^14, r=16 · 32 MiB
N=2^16, r=8, p=2 · 64 MiB
The setup you didn't have to do.
The alternative to a platform-supplied captcha credential is not "the tenant configures one". It is "the tenant ships an unprotected signup form", because the setup starts with creating an account at a third party and a step like that does not get done.
So new projects start at captcha: "platform". Signup, password recovery and magic link are bot-protected for any app on *.parsonsapps.com with no Cloudflare account of your own — and the platform credential is hostname-pinned to that project's verified link base, so one tenant's solved token cannot be spent against another tenant's project. Your own credential always wins if you bring one.
| state | outcome |
|---|---|
| Unconfigured — no credential anywhere | pass |
| Configured, request carries no token | fail |
| Configured, verifier unreachable | fail |
Three states, printed because the third one is the interesting one. When the captcha verifier cannot be reached, the request is refused — the opposite of the breach check, which fails open. A breach check failing open costs you nothing; a captcha failing open costs you a bot flood. Different failure, different posture, both decided on purpose.
The actual rate limits.
"Rate-limited" is a phrase, not a number, and a phrase cannot be checked against your traffic. Here are ours, unrounded, so you can decide whether they fit before you integrate — rather than afterwards, from a 429 in production.
| bucket | what it protects | limit |
|---|---|---|
| /v2 per key | your server-to-server plane | 300 / 60 min |
| /v2/authenticate/refresh per key | token refresh, which is chattier by nature | 3,000 / 60 min |
| /v2 per origin IP | one misbehaving host | 600 / 60 min |
| /v2 per account | credential stuffing against one user | 10 / 2 min |
| console sign-in per IP | our own console door | 20 / 10 min |
| console sign-in per email | one targeted account | 10 / 2 min |
| OAuth start | social sign-in initiation | 30 / 15 min |
| password reset | reset-mail flooding | 10 / 3 min |
| password change | an authenticated abuse path | 5 / 1 min |
| /v1/users | the older admin plane, still live | 120 / 120 min |
rl:{projectId}:…That prefix is not cosmetic. One worker serves every tenant, so an unscoped bucket would be cross-tenant denial-of-service by construction: a noisy neighbour would spend your budget. Counters live in Durable Objects, and the project id leads every key.
The From line is yours from day one.
Verify a link base with one DNS TXT record and every auth email — verification, password reset, magic link — lands on your host with your sender name. Until you do, ours catches it, so nothing is broken while you are still setting up.
Honest gate: magic link is unavailable until a link base is verified — the request answers link_base_required. A magic link's whole effect is a session, and only a page of yours should be able to create one. Do not plan on it for day one.
Twenty-three tools — and the two we took away.
Identity vendors ship MCP servers now, so "an AI can drive it" is not a differentiator any more and we will not pretend otherwise. Ours is narrower and more specific: the secret never enters the model's context in the first place, and the irreversible operations are absent from the schema rather than confirmable within it.
purge_project_data
delete_account
list_projectscreate_projectget_projectupdate_project_configrotate_project_keylist_sessionsrevoke_sessionrevoke_all_sessionslist_identitiesset_display_namechange_passwordunlink_sociallist_usersdelete_userdisable_userenable_userauth_statsAsk authOverviewUsersAPI keysActivitySettingsset_webhookget_webhookdelete_webhookwhoamidocsaudit_logUnlimited projects. No extra cost.
A project is a whole isolated world: its own users, its own keys, its own data, its own members and its own spend caps. Run your business in one, your side project in another, a client's app in a third. There is no project cap in auth and no project cap in the plan.
What we don't do.
This section is here so the rest of the page is believable. If one of these is a requirement, buy something else today — we would rather lose the sale than the argument in three months.
- TOTP / multi-factor authentication
- Passkeys
- Roles, RBAC or a permissions model
- SAML and enterprise SSO
- B2B organization primitives
- Pre-built UI components — no <SignIn/> to drop in
- Bulk data export — there is GET /v2/users/{id} and list_users to page through, and deletion that genuinely completes, but no CSV and no bulk dump. We will not claim an export we have not built.
- No hosted login page — ours was removed 2026-08-02. The door is yours, which also means you build the form.
- No shared social client — Google and Apple run on your own OAuth client. It is a real onboarding step, and Apple is a one-way door: its sub values and private-relay addresses are team-scoped, so you cannot start on ours and move later. There is no "ours" to start on.
- role, permissions and plan refused in metadata — offline verification has no row-level-security backstop, so we refuse the write instead of shipping you a privilege escalation.
- Magic link needs a verified domain first — link_base_required until you prove one.
- Enumeration-safe on your plane, deliberately not on our own console signup — a pinned asymmetry, both halves locked by tests.
We publish every difference from GoTrue in a divergence log, on the principle that we copy the reference implementation and every deviation needs a written justification or it is a bug. Fifteen rows so far, including the ones that make us look worse.
Eleven rows. We lose four.
A comparison table that only flatters its author reads as a lie, so the rows we lose are at the bottom in full weight rather than quietly omitted. If you scrolled here to find out whether we do SAML, the answer is at the end and it is no.
| Parsons Auth | Clerk | Auth0 | Supabase Auth | WorkOS | |
|---|---|---|---|---|---|
| Monthly active users billed | Never, at any size | Metered above 10,000 | Metered per MAU | — | — |
| Projects on one account | Unlimited, $0 each | — | — | One instance per project | — |
| Tenant isolation | UNIQUE (project_id, email), one worker | — | — | One instance per project | — |
| Login page lives on | Your domain — we have no hosted page | — | — | — | — |
| Rate-limit numbers published | All ten buckets, on this page | — | — | — | — |
| Password-hash parameters published | scrypt N=2^16, r=8, p=2 | — | — | — | — |
| Irreversible ops on the AI surface | Absent from the schema | — | — | — | — |
| MFA / TOTP | Not built | Yes | Yes | Yes | Yes |
| Passkeys | Not built | Yes | Yes | — | Yes |
| SAML / enterprise SSO | Not built | Yes | Yes | — | Yes — this is their product |
| Organizations & RBAC | Not built | Yes | Yes | — | Yes |
We lose four of eleven. MFA, passkeys, SAML and organizations. If you need any of them, WorkOS or Clerk will serve you better than we will, and we would rather you found that out here.
Our column is read off the shipped code, and every figure in it appears elsewhere on this page. Rival columns record only what we could confirm from each vendor's own public documentation; a dash means we could not, and we would rather leave a cell blank than guess on somebody else's behalf. We list no rival prices at all — theirs change, and ours is the only one we are in a position to promise.
Fifteen dollars — for the whole platform.
And here is the part that would annoy a salesperson: there is exactly one plan. Unlimited monthly active users on it, and no tier above it holding anything back — if auth is all you need, $15 is the whole bill.
- Every Parsons product on one account and one bill
- 1 GB database · 5 GB object storage · 200 emails/day
- 10,000 tracker tasks · 50,000 CRM contacts · 20,000 scheduler fires
"Fifteen dollars. Against what?"
Taken one product at a time, this is not the cheapest thing you can buy, and we are not going to pretend it is — a good specialist tool in any one of these categories can cost the same as us or less. The comparison that matters is the bill you actually pay at the end of the month, and there the arithmetic is not close.
14-day free trial on your first subscription · card collected at checkout · cancel any time
Billed monthly at $15, or yearly at $150 — two months free.
No per-seat pricing, no enterprise tier, no free tier — the trial, then the plan.
Answers, including the unflattering ones.
What happens when I hit 100,000 users?
Is there a free tier?
Is there an annual plan?
Can I export my users?
Do my users ever see a parsons.ai URL?
What if I need MFA, passkeys or SAML?
Can I use my own Google client?
How do I get my users out if I leave?
What happens if I stop paying?
Do I need one account per app?
Which webhooks fire?
Your login page, on your domain,
on a bill that does not move.
Unlimited monthly active users. Unlimited projects. One subscription that covers every Parsons product.
14-day free trial · cancel any time · already have an account? Open the console