AUTH4D-215 Enterprise SSO on device approval and guest upgrades

Enterprise SSO can now sign a user into the hosted device approval page and link an SSO identity to a guest account. The user’s email address is used only in the hosted page to select a connection; only the domain is sent to auth4.dev.

Device approval

When GET /device/verify returns decision: "login_required", login_methods.sso is present and true when the tenant has an enabled connection with a routed domain. The page offers “Continue with single sign-on” and asks for a work email address.

The page starts SSO with the existing device sign-in flow:

GET /t/{tenantId}/sso/start?client_id={clientId}&browser_flow_id={flowId}&flow_kind=device&domain={domain}

flow_kind=device is accepted only for a live, tenant- and client-bound device sign-in flow and its browser-flow cookie. On success, the SSO callback returns to /login/device with a one-time proof_id and proof_purpose=sso_login. The page passes that proof to POST /device/sign-in/resume, which creates a browser session and returns the pending user code. The user still reviews the application, scopes and code, then explicitly approves or denies the device. SSO does not approve the device by itself.

Guest upgrades

The hosted guest upgrade page offers single sign-on alongside email and social identities when the tenant has an enabled connection with a routed domain. The browser upgrade and native upgrade-intent flows each bind a short-lived server-side marker to their existing guest-linking intent and browser cookie before starting SSO:

GET /t/{tenantId}/sso/start?client_id={clientId}&browser_flow_id={flowId}&flow_kind=guest_upgrade&domain={domain}

flow_kind=guest_upgrade requires that server-side marker and the matching hosted-login flow. The callback returns to /login/upgrade with a one-time SSO proof (or a fixed error code). The page asks the user to confirm linking before it completes the browser upgrade or native upgrade intent. An existing account is never merged into the guest; an SSO identity already owned by another user returns identity_in_use.

The default SSO start mode remains the browser authorization flow described in AUTH4D-148 (repository file docs/api-spec/auth4d-148.md). Device and guest-linking modes cannot be selected with an ordinary authorization flow, and tenant, client, flow and cookie bindings are checked again at the callback and proof-consumption steps.