Enterprise SSO

Built, Enterprise plan only — not yet exercised end-to-end against a real customer IdP. The authorize/callback flow described below is real, deployed code, not a stub or a mockup — but as of this writing it has only been verified via direct discovery-document checks and code-level review, not a live login against a real Okta/Auth0/Entra ID/Google Workspace tenant. Configured from /dashboard/enterprise/sso. OIDC only — SAML is not supported.

How it works

SSO is per-tenant: each Enterprise account configures its own identity provider, and login is routed to the right one based on the email domain the user types in — not a single fixed provider for the whole platform.

1. A user on the login page enters their work email and clicks Continue with company SSO.
2. GET /api/auth/sso/authorize?email=... looks up which account's SSO config matches that email's domain, fetches the provider's real OIDC discovery document ({issuer}/.well-known/openid-configuration), generates a state/nonce/PKCE pair, and redirects to the identity provider's real authorization endpoint.
3. The user authenticates with their own IdP as normal.
4. GET /api/auth/sso/callback exchanges the authorization code for an id_token, then verifies its signature against the identity provider's own JWKS (jose's createRemoteJWKSet + jwtVerify, checking issuer and audience) — the token is cryptographically verified, not just decoded and trusted.
5. The domain used for authorization is re-derived from the verified id_token's email claim, not the email the user originally typed — the query-string email is only ever used to route the redirect, never trusted for identity.
6. If the domain matches the account's configured allowedDomains, the user is logged in (existing account) or provisioned (new account, if autoProvision is on).

Setup

From /dashboard/enterprise/sso, an Owner or Admin configures:

Test Connection fetches your IdP's real discovery document and reports back what it finds — it catches a wrong issuer URL or a non-OIDC provider, though it can't fully validate clientId/clientSecret until a real login is attempted (that only happens during the actual authorization-code exchange).

Auto-provisioned accounts

A new user logging in via SSO for the first time (with autoProvision on) is created and added to the SSO config owner's workspace as a Viewer — not Owner or Admin. The reasoning: a work email alone shouldn't grant admin rights over the whole workspace. An Owner or Admin can raise their role afterward from the team management page.

Security notes, stated plainly

• An existing-account email match is not enough to log someone in. If the verified id_token's email belongs to an account that already exists on Valta, that account must already be the SSO config's owner or an active member of its workspace — otherwise the login is denied with account_not_provisioned_for_sso. Without this check, anyone on an Enterprise plan could point their own SSO config at an identity provider they fully control, assert an arbitrary victim's email in a self-signed configuration, and get logged straight into that victim's real Valta account. This is a real, deliberate defense against account takeover, not a hypothetical.
• Domain ownership is not independently verified. Configuring allowedDomains: ["anycompany.com"] doesn't require proving control of that domain — the actual security boundary is the check above (an attacker's forged identity still can't reach anyone else's real account), not domain verification. If you need stricter guarantees here, talk to us before relying on this for a high-stakes domain.
• The state value is single-use. It's deleted from sso_login_state the moment the callback consumes it, regardless of outcome — a replayed callback URL never verifies twice.
• SAML is not implemented. If your IdP only supports SAML and has no OIDC application type, SSO isn't available for it yet.