Sign In With Sovereign ID — No OAuth Provider, No MAU Fee
Sign in with Sovereign ID is a button on your site: the user signs with keys on their device, your backend verifies locally — no Auth0, no JWKS, no per-user tax.
OAuth taught the web a habit: every "Sign in with X" button routes through a company you register with, configure client IDs for, and eventually pay per monthly active user. That company sees every login, on every site, every time. Sign in with Sovereign ID is the opposite habit. The visitor already holds a MATA wallet. They sign a token on their own device. Your backend checks the cryptography in process. No fetch to MATA. No JWKS refresh. No DID resolver on the hot path. No portal account for you.
This article is for people who run a website. The wallet, DID, and IAMHUMAN story for users lives in digital identity. The npm install and the business-tab walkthrough live in the Freedom Guide. The restored product page is Integrations. What follows is why the button exists, what you actually store, and what it costs — which is not "a slice of your MAU."
Why Sign In With Sovereign ID Replaces The OAuth Middleman
Auth0, Clerk, Firebase Auth, "Sign in with Google" — they are convenient because they are the identity provider. Convenience has a meter. Cross the free tier and you are buying logins the way you buy bandwidth. Worse than the invoice: the provider's logs are a map of who used your product, when, and from where, sitting on a disk you do not control. The Electronic Frontier Foundation has spent years documenting how identity intermediaries become surveillance intermediaries. Sign in with Sovereign ID is built so that map cannot exist on our side. At runtime, we are not in the loop.
The NIST Digital Identity Guidelines describe authenticators bound to the user, not leased from a broker. A MATA passkey in a Secure Enclave, StrongBox, or TPM is that authenticator. Your site does not need a copy of the secret. You need a verifier that can check a signature. That is a library, not a SaaS.
Trust, Security, and Incentive are not decoration here. Users trust keys they hold, not a dashboard at an IdP. Security is local verification plus device-bound keys — phishing a password you never typed is a different sport. Incentive is aligned: MATA's business is the wallet and the network, not a tax on your growth. Relying parties that adopt Sign in with Sovereign ID are how the protocol spreads, so putting a price on the button would be shooting the messenger.
The Federal Trade Commission's consumer privacy guidance is full of products that held more identity data than they needed "to make login work." This design holds less on purpose.
How Sign In With Sovereign ID Works On Your Site
You ship a button. Behind it, the @matanetwork/sovereign-id SDK finds the visitor's MATA wallet — browser extension or native app — asks them to consent to the claims you requested, and returns a signed JWT. Your backend hands that JWT to @matanetwork/sovereign-id-verify (JavaScript) or to mID (Rust). The verifier does not call home.
Sign In With Sovereign ID: The Button, The JWT, The Verifier
React sites install @matanetwork/sovereign-id-react as well; vanilla, Svelte, Vue, and Solid use the core SDK. Exact snippets live in the Freedom Guide so they do not rot in a blog post. The shape does not: one component on the page, one verify call on the server.
The JWT carries a stable DID plus the claims the user agreed to show you — not a dump of the vault, not their password list, not a standing OAuth refresh token you could abuse later. Resolution data is in the token (embedded genesis roster and verification methods). There is no /token back-channel. There is no JWKS URL to cache and rotate. If verification succeeds, you know which identity signed and what they signed. If it fails, you get a typed error — user_denied, timeout, and the rest — not a mystery 401 from a vendor.
What Your Backend Should Store
Map the DID to a row in your users table on first sight. That identifier is stable across sessions and across the user's own devices. You are not storing their passphrase. You are not storing a MATA API key, because Sign in with Sovereign ID does not issue you one.
Do not treat the JWT as a durable session cookie you never re-check. Verify on the request path the way you would verify any other signature. The Privacy Rights Clearinghouse is a graveyard of "we cached identity tokens and then the cache leaked." Local verification is cheap. Use it.
You still own your product sessions, roles, and billing. Sovereign ID answers "is this the same human who was here yesterday?" It does not replace your authorization model. Pair it with whatever you already do after a successful login.
Referral Attribution Without A Tracker Farm
If a visitor does not have MATA yet, the flow can send them to install and to my.mata.network/signup. By default the SDK stamps ?ref=<your-domain> on those links. Signups that complete inside the window credit your account — the same 5% lifetime share documented in getting paid for helping MATA grow. One code per relying party. You can opt out.
That cookie is deliberately small: scoped, time-boxed, not a cross-site dossier. Attribution is a feature of the button, not a reason to run a surveillance stack. If you are paid to recommend MATA, say so. The FTC endorsement rules still apply to you; the ref parameter is just an identifier.
What Sign In With Sovereign ID Costs — And What You Still Owe Users
Cost here means money, operational coupling, and honesty about what ships today.
Privacy: MATA Cannot See Your Users Log In
There is no login webhook to our servers. We cannot produce a list of who signed into your app last Tuesday, because that list was never written here. The user signs locally. You verify locally. That is the whole runtime. Compare that to an IdP that must see the event to bill you for it.
This is also why Sign in with Sovereign ID is not "login as a service" you page us about when it is down. If your verifier is deployed, verification works. Our uptime is not your auth uptime. That is the point of rebuilding identity as a primitive instead of renting it.
No Client ID, No MAU Meter, No Portal
Drop the SDK. Deploy the verifier. Sign in as many users as you want. There is no free-tier cliff, no seat license, no "contact sales for SSO." Identity should be a utility. Charging per login would contradict the Incentive primitive the rest of the protocol is built on.
MATA still has a business — wallets, banking rails people opt into, cloud they choose, small-business tools. The button is distribution, not SKU #47. If that sounds too clean, read the Wallet & Identity page and the referral article together: we get paid when people use a sovereign stack, not when you meter our logo.
How To Add Sign In With Sovereign ID Today
Create a MATA account if you do not have one — you need a wallet to test the happy path as a user. Install the packages from npm. Wire the button and the verify call. Put the integration on a staging host and sign in with your own device. Production is the same binaries.
A dedicated docs portal with a live playground is coming; today the long-form reference is docs/sovereign-id/ on GitHub plus the Freedom Guide business tab. The protocol is MIT-licensed on the JavaScript side; mID is Apache-2.0 OR MIT. Experimental edges exist — treat the packages as living software, pin versions, read the changelog. Do not wait for a sales engineer. There is not one.
If you already imported passwords and run the browser extension, you are the same human the button is for. Add Sign in with Sovereign ID where you would have pasted an Auth0 snippet, then delete the Auth0 snippet.