Hosted Auth

Unified flow

XID does not expose separate end-user registration and login products. Hosted Auth starts from the same identifier step and decides login or user creation from organization policy and account state. A guest or credential sign-up with intent=sign-up then creates a top-level Tenant with an Email, Organization name, and URL slug. A guest Email stays pending without reserving an account address; the new owner can read Console data, and verifies that Email before the first business change. The same Email in another Tenant remains a separate account.

Bootstrap defaults enable email magic link and email OTP only. Password, WhatsApp OTP, SMS OTP, passkey, social OAuth, and enterprise SSO stay hidden until the organization policy and required credentials enable them.

Passwordless email magic-link and OTP requests freeze the sign-up intent, server-owned continuation, application client, and invitation row ID when the challenge is created. Social OAuth invitation authorization likewise validates the raw capability before redirecting upstream, persists only the invitation row ID in its one-time state, and ignores caller-owned token routes on callback. Verification cannot rewrite those fields. Raw invitation capabilities are never stored in these flow contexts; when MFA interrupts acceptance, XID uses a short-lived signed continuation bound to the Tenant, User, Session, and invitation.

flowchart TD
  Browser --> authorize["/authorize"]
  authorize --> signIn["/sign-in"]
  signIn --> config["/auth/config"]
  config --> methods["WebAuthn / Password / OTP / SSO"]
  config --> signup["guest or intent=sign-up"]
  signup --> createOrg["/create-organization"]
  createOrg --> readOnly["Console reads"]
  readOnly --> verifyEmail["Verify Email"]
  verifyEmail --> mutations["Business mutations"]
  methods --> code["code"]
  methods --> mfa["/auth/mfa/passkey/*"]
  mfa --> code

Configuration endpoint

GET /auth/config returns the public Hosted Auth configuration for the organization. Provider secrets and disabled providers are not returned to the browser.

Identifier policy

• Organizations can require email identifiers, username identifiers, or both.
• Allowed and blocked email domain lists apply before user creation.
• Force SSO hides local methods when an enterprise connection is required.

WebAuthn and passkey boundaries

• Passkey sign-in is primary AAL2 authentication. Password or OTP sessions can complete MFA through /auth/mfa/passkey/* with user verification required.
• Organization policy attestationMode selects none, indirect, or direct enterprise attestation during passkey registration.
• WebAuthn credential parameters advertise ES256, RS256, and EdDSA. Syncable passkeys remain AAL2 even after MFA.
• urn:xid:aal3 is not currently issued. WebAuthn UV and BE/BS flags do not prove the non-exportable hardware key required by NIST; AAL3 requests fail explicitly and the current maximum mapping is AAL2.