Sigma Auth vs Clerk
Clerk is a managed authentication service with an unusually good component library. Sigma Auth is self hostable, key based, and MIT licensed. They are optimizing for different things, so the honest answer depends on which of those things you need.
Choose Clerk if
- You want working authentication this afternoon, with prebuilt components
- Email, social, and passkey logins cover your users completely
- You need organizations, invitations, and member roles as shipped features
- A managed vendor relationship suits your compliance story
Choose Sigma Auth if
- Identity has to run on infrastructure you control
- Users should hold their own keys rather than a credential in a vendor database
- Entitlement should follow an asset a user holds, not a row you maintain
- You want the option to fork the software and keep running it indefinitely
Feature comparison
| Clerk | Sigma Auth | |
|---|---|---|
| Hosting | SaaS only | Self hosted or hosted |
| License | Proprietary | MIT |
| Pricing model | Free tier, then per monthly active user | Free self hosted. The hosted service currently has no paywall |
| Primary authentication | Email, social providers, passkeys, and Web3 sign in | secp256k1 signatures, plus OAuth providers |
| Where the credential lives | Managed by Clerk | On the user device. The private key is never transmitted |
| Prebuilt UI | Extensive component library | Hosted auth pages, a smaller component set |
| Account recovery | Provider managed recovery flows | Encrypted backup file the user controls, plus OAuth linked restore |
| Protocol surface | SDK first, with OIDC support | OAuth 2.0 and OpenID Connect |
| Developer integration | The Clerk SDK and its component library | OAuth 2.0 directly, or @sigma-auth/better-auth-plugin for projects already running Better Auth |
| User database | Held by Clerk | Yours |
| Access control | Roles and permissions you define | Roles, plus NFT ownership, token balance, and BAP allowlists |
| Wallet infrastructure | Not included | Included through Droplit (tap, push, fund, mint) |
| Framework support | Strongest in React and Next.js | Any framework that speaks OAuth 2.0 |
| Exit path | Export users, then rebuild the auth layer | Self host the same software |
Verified on 21 August 2026. Both products ship frequently, so treat this as a snapshot.
Where Clerk is strong
Pretending otherwise would make the rest of this page less useful to you.
The fastest route to a working login
Drop in a component, get a styled and accessible flow the same day. If time to first login is your binding constraint, Clerk wins that outright and it is not close.
B2B primitives are already built
Organisations, invitations, roles, and member management arrive as shipped features rather than as something you assemble and then own forever.
Login methods people already recognize
Email codes, social providers, and passkeys need no explanation. A key based flow needs one, at least the first time a user meets it.
Somebody else carries the pager
Uptime, patching, abuse handling, and email deliverability become the vendor's problem. That is worth real money, and self hosting means taking it back.
Where Sigma differs
These are structural choices about who holds what, which is why they are hard to add later.
Self sovereign identity
Users sign a challenge with a key held on their own device. Sigma never receives the private key, so there is no credential store to breach and no password to reset.
No vendor lock in
MIT licensed and deployable on your own infrastructure. Moving off the hosted service is a deployment decision rather than a rewrite of your auth layer.
Anchored on BSV, generated from a key you already hold
Two layers. The identity attestation hashes live on BSV through BAP, which is the anchor chain and does not move. Generating the identity is separate, and the key can be one a user already holds on Ethereum, Bitcoin, Bitcoin Cash, Bitcoin SV, Litecoin, Avalanche, ICP, or Solana. See how.
NFT gated access
Gate a route on an asset the user holds. Entitlement becomes transferable and independently verifiable instead of a flag only your database knows about.
Sign once with a wallet you already have. No new seed phrase, and the private key stays where it is.
Moving from Clerk
Sigma speaks OAuth 2.0, so most of the work is configuration rather than a rewrite. Point your client at the Sigma authorization endpoint, map users to public keys, add the backup and restore path, then run both providers in parallel while users migrate on next sign in.