Why We Built Our Own Sign-In Instead of Buying Auth0 or Clerk

Every company that ships a login screen makes this decision once, usually in an afternoon. The shortlist writes itself: Auth0, the incumbent Okta owns; Clerk, the React-native newcomer with the polished components. Both are good. Buying one is almost always the right answer, and we did not.

This is the write-up of that decision — what we would have been buying, the single requirement that ruled it out, and the bill we are still paying for building instead. It is not a feature comparison, because we would lose one. Auth0 has more features than Ciphera ID will ever have, and that was never the axis.

TL;DR:

We wanted a login where a Ciphera operator with full database access cannot read a user's password or their email address. No hosted identity platform sells that, because their own recovery flows require holding both. So we built the sign-in ourselves on OPAQUE (RFC 9807) and paid for it in features we now do not have: no password reset, no admin user search, no SOC 2, and no SDK for anyone else. The reusable half is open source — Tessera, Apache-2.0. The sign-in itself, Ciphera ID, is internal infrastructure and is not for sale.

Update, 03-09-2026 — this post was published in July 2026 as a three-way product comparison, which implied Ciphera ID was a thing you could adopt. It never was. Rewritten as the build-versus-buy story it always should have been; the URL is unchanged. See how signing in to Ciphera works for the current, non-marketing description. Corrected the same day: account recovery is switched off while we finish the ceremony, so the bill for building this ourselves is currently higher than the post first said — there is no password reset and no working recovery, which makes the password the only way in.

What we would have been buying

It is worth being precise about the thing we turned down, because both products are genuinely strong and this write-up is worthless if it pretends otherwise.

Auth0 is a full identity platform, acquired by Okta in May 2021 for around $6.5 billion. It is standards-complete: OpenID Connect and SAML, a per-tenant JWKS endpoint at /.well-known/jwks.json for asymmetric RS256 verification, WS-Federation, OAuth 2, plus Actions for extensibility, adaptive MFA, and hardware-key and passkey support. The free plan carries 25,000 monthly active users (raised from 7,500 in September 2024), no credit card. Its compliance shelf is deep: SOC 2 Type II, ISO 27001/27017/27018, PCI, FAPI, CSA STAR, HIPAA Business Associate Agreements.

Clerk (Clerk, Inc., founded 2019, $50M Series C in October 2025) took the newer approach: drop-in <SignIn />, <UserButton /> and <OrganizationSwitcher /> components that give you a working, styled auth flow in an afternoon. Its free tier is 50,000 monthly active users per app as of February 2026; Pro is $25/month. SOC 2 Type II, HIPAA on Business and up, multi-tenant Organizations, webhooks via Svix, enterprise SSO by SAML and OIDC.

Either would have given us, on day one, a set of things we still do not have: social login, SAML for enterprise buyers, an admin console that can search users by email, a password-reset flow that works the way every user on earth expects, and an audited compliance posture we could hand to a procurement team. That is a serious list. Writing it down honestly is the only way the rest of this post means anything.

The requirement that ruled them out

Ciphera sells privacy infrastructure. The claim we make on every product page is that we cannot read your data — not that we promise not to, that we structurally cannot. A login is where that claim is easiest to quietly break, because authentication is the one place where the user hands you a secret on purpose.

When a user sets a password with Auth0 or Clerk, the server receives that password over TLS, hashes it with a strong algorithm like bcrypt, and stores the hash. This is the industry-standard, correct way to store passwords, and both do it competently. But it means the plaintext password passes through the provider's servers at every login, and what sits at rest is a hash of the user's actual password — an artifact an attacker who steals the database can attack offline, one guess at a time.

The same is true one layer up, for profile data. A hosted identity platform holds your users' email addresses in plaintext because it needs them: to send the password-reset link, to render the admin user list, to deduplicate accounts. Those are not sloppy design choices. They are the load-bearing requirements of the product being sold.

We wanted the opposite property, and it is not a setting you can turn on.

Ciphera ID uses OPAQUE (RFC 9807), an asymmetric password-authenticated key exchange. At registration the user's device stretches the password with Argon2id and runs a blinded exchange with the server. Blinded means the server completes registration without ever seeing the password, a hash of it, or even the salt. What the server stores is an opaque credential record. Every subsequent login repeats that blinded exchange. The plaintext password, and any reversible derivation of it, never touches Ciphera infrastructure at any point.

The consequences are concrete, not rhetorical:

The exchange also yields key material the client can use to unwrap a vault key, which is how the second half works. Your name and email are sealed in a vault encrypted on your own device. Our account table has no email column and no name column; to find your row at sign-in we use a blind index, a keyed hash of your address that identifies the account without revealing it. An operator with full database access sees a UUID, a blind index, a credential record, a wrapped key and a blob of ciphertext. We wrote the full itemised version of this in what we see about you, and what we don't.

None of that is a knock on Auth0 or Clerk. It is a property neither is trying to sell, because it is incompatible with most of what makes them worth buying.

The bill, itemised

Building your own authentication is famously a bad idea, and the standard warning is about getting the cryptography wrong. That was not the expensive part. The expensive part was everything the cryptography then makes impossible.

There is no password reset. There cannot be. A reset link works by proving control of an email address the provider can read, then letting the user set a new password the provider stores. We hold neither side of that. Recovery is meant to run on a 24-word phrase generated on the user's device at signup, which we never hold. Account recovery is switched off while we finish it, so today the password is the only way in and losing it alone loses the account. Every hosted platform would have handed us the familiar flow for free.

There is no admin console, and there never will be. Support cannot look up a user by email, because there is no email to look up. This is not a missing feature we are getting to; it is the same design decision as the one above, seen from the support desk. It is also the single hardest thing to explain to anyone evaluating an identity system on a feature grid.

We carry the on-call. Auth0's and Clerk's uptime is somebody else's job and their incident reviews are somebody else's late night. Ours are not.

We have no SOC 2 Type II, and Tessera has not had an independent third-party security audit. What exists is a published self-audit and threat model, cross-language parity gated in CI — a WASM-to-native handshake plus byte-exact Go-to-TypeScript vault and blind-index checks — and a language-neutral conformance kit any implementation can check itself against. That is real engineering and it is not the same thing as an external attestation. Auth0 and Clerk both carry certifications we do not. Read the source rather than taking our word.

The feature list stays short. No social login, no SAML, no adaptive MFA, no prebuilt component library. Every one of those is an afternoon with Clerk and a quarter with us, and most of them we will simply never build.

If your product does not need the property in the previous section, this bill buys you nothing. That is the honest version of "build versus buy": we did not build because building is better. We built because the thing we needed was not for sale.

Where the data would have lived, and who can compel it

Architecture decides what a server can read. Jurisdiction decides who can make it read. This was the second input, and it pointed the same way.

Auth0 is operated by Okta, Inc., a Delaware-incorporated, San-Francisco-headquartered, Nasdaq-listed US company. Clerk is operated by Clerk, Inc., a US company hosting primarily on Google Cloud and Cloudflare; its own GDPR notice states that website and account data goes "directly to the USA," and it offers no EU or regional data-residency option. Both rely on the EU-US Data Privacy Framework plus Standard Contractual Clauses to legitimise EU data transfers.

That legal basis is under real strain in 2026. The framework's adequacy decision (Commission Implementing Decision 2023/1795) survived its first challenge when the EU General Court dismissed Latombe v Commission on the merits in September 2025 — but that ruling is on appeal to the Court of Justice. Then, on 29 June 2026, the US Supreme Court held 6-3 in Trump v. Slaughter that for-cause removal protections for Federal Trade Commission commissioners are unconstitutional, overruling a 1935 precedent. Within a day, the privacy group noyb formally asked the European Commission for an "orderly withdrawal" of the framework, noting the adequacy decision references FTC independence 259 times. Legal analysts at the IAPP have pushed back that the specific redress mechanism for EU complaints rests on a separate Executive Order, not the FTC — so this is contested, not decided. "Contested and on appeal to the CJEU" is still not a foundation we wanted under the login of a privacy company.

Separately, US law — the CLOUD Act, and Section 702 of FISA (which itself lapsed in June 2026 with existing certifications grandfathered into 2027) — reaches US-headquartered companies regardless of where data is physically stored. That is a structural feature of using a US provider, not a criticism of any one company's conduct.

Ciphera runs on Swiss infrastructure — Exoscale, in Zurich — operated by Ciphera BV, a Belgian company under GDPR and the Swiss FADP. There is no US company in the critical path, deliberately. Combined with OPAQUE, the practical result is that a lawful compulsion order lands on a server holding a credential record and a blob of ciphertext.

Being the target versus being a target

An honest write-up has to note that the incumbents are large targets, and that being a target has consequences neither of them chose.

Okta, Auth0's parent, disclosed a breach of its support case-management system in October 2023: an attacker used a stolen service-account credential to reach support files, and HAR files in those cases contained session tokens later used to hijack sessions at five customers, including 1Password, Cloudflare and BeyondTrust. A November 2023 follow-up disclosed that the stolen report contained names and email addresses of effectively all Okta Workforce and Customer Identity customers. That followed the January 2022 Lapsus$/Sitel incident. Okta stated that Auth0's case-management system was unaffected by the 2023 breach.

Clerk has shipped its share of CVEs: a January 2024 privilege-escalation flaw in @clerk/nextjs (CVE-2024-22206); an interaction with the Next.js middleware-bypass CVE-2025-29927 where Clerk initially told customers they were unaffected and then publicly retracted, calling it "a significant error"; a July 2025 webhook-verification flaw (CVE-2025-53548) that accepted forged events; and a November 2025 OAuth-flow bypass in clerk-js (CVE-2025-63700).

We are not throwing stones from a glass house. We have no external audit, a smaller team, and a shorter track record; the probability that we have a bug they do not is high. The argument is narrower and it is about blast radius, not competence: when a provider holds password hashes and plaintext profile data, a breach of that provider is a breach of that data. When the architecture holds neither, the same class of breach exposes less. Choosing to build did not make us safer. It made the worst case smaller.

What we actually shipped — and what it deliberately is not

Ciphera ID is the sign-in behind our own applications. One account reaches Pulse and the services that follow it, over OAuth 2.0 with mandatory PKCE. It runs the authentication ceremonies — sign in, sign up, recovery — and nothing else; settings live in whichever application you are using.

It is not a product, and we would rather say so here than let anyone discover it after a procurement call. There is no self-serve client registration: adding an application takes a database migration by us. There is no OpenID Connect discovery document and no JWKS endpoint, so nothing external can verify our tokens independently — the token model is a shared secret suited to our own backend fleet. There is no "Sign in with Ciphera" SDK, no social connectors, no SAML. There is no plan, no price and no checkout; the billing tables were removed rather than left dormant. If your requirement is "let external developers register apps and sign in through my IdP," Auth0 and Clerk are built for that and this is not.

The half that is reusable is the cryptography, and it is open source. Tessera is our OPAQUE implementation, published under Apache-2.0 across three repositories:

• ciphera-net/tessera — the Rust OPAQUE core and a sidecar you run alongside your backend, talking over a Unix socket. On crates.io.
• ciphera-net/tessera-go — the Go server SDK: pooled sidecar client, blind index, and versioned AES-256-GCM vault sealing.
• ciphera-net/tessera-ts — the browser SDK, on npm as @ciphera-net/tessera: the WASM OPAQUE client, vault key wrap/unwrap, WebAuthn-PRF passwordless unlock, and BIP-39 recovery.

If you want the property described earlier, Tessera is the part you can take. It does not require adopting anything else of ours, and it is the honest answer to "can I use what you built" — not the login service, the library under it.

How to make this call yourself

Route by the requirement, not by the architecture argument.

• You need a general-purpose IdP — social login, SAML for enterprise customers, an admin dashboard, standards-based OIDC other systems consume. Buy. That is Auth0's and Clerk's home turf and building it yourself is a multi-year detour. Choose between them on ecosystem fit: Clerk if you live in React and want prebuilt UI fast; Auth0 if you need the deepest standards and compliance surface.
• You are cost-sensitive at the free tier. Buy. Both are generous now; watch the step-ups, where enterprise SSO connections and B2B tiers are what move the bill.
• You want an admin console, or support that can look up a user by email. Buy. This is not a small caveat of the zero-knowledge model — it is the whole thing, and it will hit your support desk in week one.
• Your product's central claim is that you cannot read your users' data, and the login would be the exception. Then buying breaks the claim, and the question stops being build-versus-buy and becomes whether the claim is worth the bill above. Build on Tessera rather than from scratch; the cryptography is the part you should not be writing twice.

The tools change; the question underneath doesn't. It is not "which auth provider has the most features" — Auth0 wins that outright, and it isn't close. It is "what does my auth provider hold about my users, and who can make it talk." Auth0 and Clerk answer that with policy, certifications and a US legal posture, which is a legitimate answer for most products. We needed to answer it with architecture, and that is the only reason we wrote our own.