Ship your product.
Skip the platform.

bizbasics is a B2B control plane — identity, billing, entitlements, and an app catalog. You bring the product; we handle sign-in, who-can-use-what, and getting paid. Wire it up in an afternoon.

# 1 · the browser already carries a signed access cookie (bb_at),
#     set by the platform on every *.bizbasics.ai at sign-in.

# 2 · verify it locally against the platform JWKS — no callback:
verifyRS256(bb_at, jwks("auth.bizbasics.ai/.well-known/jwks.json"))
# → { user_id, email, org_id, role, plan, apps, quotas, iss, exp }

# 3 · your slug in `apps`? sign them in. done — one local check, no login code.

# ── legacy, still supported: one-time ?token= handoff ──
#   GET https://your-product.com/auth/sso?token=…  then exchange it:
curl "$AUTH/api/v1/internal/verify-app-token?token=$T" -H "X-Internal-Key: $BBAS"
# → { user_id, email, full_name, org_id, role, app, is_platform_admin }
#   identity only — apps/plan come from bb_at or the catalog API, not here.

How it fits together

Customers sign in once. The control plane owns identity, billing, entitlements, and the catalog — and every product, ours or yours, plugs in over the same four contracts.

Everything but your product

Sign-in in one round-trip

The canonical path verifies the bb_at cookie locally against the platform JWKS — no callback, no shared secret. The diagram below shows the legacy one-time-token handoff (still supported, and what relay/monk use): the platform hands your product a one-time token, you exchange it server-to-server, then mint your own session.

Three steps to live