Your existing Supabase / Firebase / Auth0 session, recognised by Business Dash

When a platform says "the customer portal needs to authenticate," what they usually mean is "your customers need to sign in to us, not to you." That breaks the consumer-side architecture you've already built. It's why most platforms fail the "what if I already have auth?" question.

Business Dash's data-layer architecture means auth is also exchangeable: you bring the identity, we bind it to the Business Dash user record, and every gated read in the SDK follows the session your customer already has.

POST /api/package/v1/auth/exchange-foreign-identity accepts a JWT signed by a trusted issuer (v1: Supabase Auth via HS256). Business Dash verifies the signature, reads the email claim, finds the matching users row that belongs to the requested org, and mints a Business Dash tenant session token.

You drop the token in your httpOnly cookie. Every subsequent SDK call uses it. The customer never knows another auth provider exists.

V1 (today): Supabase provider. Email-claim matching against the org's existing Business Dash user records. The org's user must already exist in Business Dash (added via the dashboard or another flow) — we don't auto-provision strangers off a JWT, deliberately.

V2 (deferred): Firebase Auth and Auth0 providers (RS256 JWKS verification). Optional auto-provisioning with a per-org allowlist of email domains. Foreign-identity link table so the BD user can be referenced by the foreign sub claim independent of email (some IdPs rotate email but keep sub stable).