The Identity-Aware Front Door: SSO for a 3-Person Tool

TL;DR: Authentication is a platform property, not application code. An identity-aware proxy in front of every cell authenticates each request against the org’s existing provider, hands the app a verified user, and makes sharing a membership list instead of a code change. Zero-config personal auth for individuals; org SSO for teams — priced for 3–10 people, not 500 MAU.

The request path

colleague clicks link
  → front door: signed in with work account? (Google / Okta / Entra)
  → yes: request forwarded with verified user in header/context
  → app: pure business logic, zero auth code

The app never sees a password, a token exchange, or a session table. It receives who this is and gets on with the invoice reconciliation. “Send this to Priya” becomes adding an email to a list — no OAuth wiring, no user model, no redeploy.

Two tiers: personal, then org

• Personal (zero-config). Email/Google sign-in that works with no setup — for the individual builder sharing with a partner or a friend. This is the acquisition motion: simplest possible sharing.
• Org (the monetization motion). SAML/OIDC via the org’s IdP, group-based sharing, an audit trail of who accessed what, and SCIM-shaped deprovisioning: a departing employee loses all twenty tools at once, in the identity system HR already operates.

The sequencing is deliberate. Sharing with a second person is the moment a free user becomes a team conversation — acquisition, retention (sprawl accumulates on free idle), and monetization (identity + environment) in that order.

The gap it closes: no middle tier anywhere

The auth cliff in one table:

Nobody sells “Google SSO for 3–10 people who’ll never need SCIM” — which is why org identity at the bottom of the pricing page, not the top, is the wedge. Lovable and Create already proved non-seat pricing is table stakes; the defensible version is narrower and exactly this.

What IT gets (the sanction-vs-ban argument)

Some IT organizations ban unsanctioned tools on principle. The front door converts that objection into a checklist:

• Per-cell access log — who opened what, when. Cheap to build on a proxy we already own; decisive in a security review.
• Central deprovisioning — one removal in the IdP, twenty tools closed simultaneously.
• Ownership transfer — tools survive their authors leaving.
• Egress + spend caps per cell — the membrane’s half of the story (see membrane security).

The optional SDK (never required)

Apps that want per-user behavior — my queue, my saved view — read the verified user through a small identity SDK. The rule holds: the app may know who you are; it never authenticates you.

Limits, stated plainly

• SSO/SCIM-shaped deprovisioning ship with the team tier, not day one of beta; personal auth comes first.
• No final pricing published — but the model is fixed: identity and environment on the org plan, never per-seat.
• If your policy requires self-hosted identity on own metal, say so in the beta form; self-host comes later, if at all.

FAQ

Does my app need any auth library? No. No OAuth code, no session middleware, no user table. Read the verified-user header only if you want per-user logic.

What providers are supported? Google/email zero-config for personal; SAML/OIDC to the org’s IdP (Google Workspace, Okta, Entra, and equivalents) for teams.

How is this different from Cloudflare Access? Same architectural pattern (identity-aware proxy), different packaging: per-app share lists including external guests, no Zero Trust policy fluency required, priced for tiny audiences.

Want colleagues signing in with work accounts, not new passwords? Deploy now.