All packsMulti-Tenant Auth & RBAC CoreSolve
sso auto link account by email takeover vulnerability
Auto-linking an SSO login by email is an account-takeover vector
Automatically attaching a new SSO identity to an existing account just because the emails match lets anyone who controls that email on the SSO side take over the account.
This is one of the things Multi-Tenant Auth & RBAC Core already handles. Sign-in, organisations, invites and roles — with one customer's data provably unable to reach another's.
Is this you?
If a user logs in via a new SSO provider and the app automatically links that login to an existing account purely because the email addresses match, then anyone who can create or control an account with that same email address on the SSO provider's side -- not necessarily the real account owner -- gets full access to the existing account the moment they "sign in with" that provider.
Why this one is easy to get wrong
Auto-linking by email feels like good UX ("we recognized you, no extra step needed") and is a common pattern in tutorials that don't dwell on trust boundaries between identity providers -- the vulnerability requires reasoning about who actually controls a given email address on a third-party system, which is a security-specific concern outside what a feature-focused auth flow naturally surfaces.
What you get instead
Core decision 16 states the rule as a hard never: never auto-link an SSO identity to an existing account by email. The v1 schema (auth_identities, keyed by provider + provider_user_id) has no linking flow implemented at all -- adding OIDC or SAML later means new identity rows and one login route, with account linking left as a deliberately unbuilt, separately-designed feature rather than an implicit default.
Source: ARCHITECTURE.md core decision 16 — checkable in the pack you receive
How you actually use this
You don’t install a library or wire up an SDK. Your own coding agent builds the code in your project, and you keep it — no runtime dependency on us.
Step 1
Download and unzip
You get a folder: the docs that tell an agent what to build, a starting skeleton, and the test suite that decides when it's done.
Step 2
Open it in Claude Code or Cursor
Point your coding agent at the folder. Nothing to install, no account with us, no API key.
Step 3
Paste one prompt
The pack contains the exact prompt. Paste it as your first message and leave it alone — it works through the build itself, choosing a cheaper or stronger model per task.
Step 4
Run ./verify.sh
One command. It prints a pass or fail for every check. Green means the build is done — the same script we ran to produce the receipt on this page.
Typical build: about 12 minutes of your agent working, mostly unattended. Then you integrate the working module into your app the way you would any code you’d written yourself.
Why you can believe this
2 of 3 runs passedWe ran this pack from an empty folder 3 times and published exactly what happened — every check, the model, the token cost, the wall time. Not a testimonial, and not our opinion: the same verify.sh you run yourself. Read the full receipt →