托管认证 | XID

统一流程

XID 不提供相互独立的终端用户注册和登录产品。Hosted Auth 从相同的标识符步骤开始，并根据 Organization 策略和账号状态决定登录或创建用户。访客或使用凭据且 intent=sign-up 的注册随后会创建一个顶级 Tenant，并填写 Email、Organization name 和 URL slug。访客 Email 保持待验证状态，不会预占账号地址；新所有者可以读取 Console 数据，但必须在首次业务变更前验证该 Email。相同 Email 在另一个 Tenant 中仍属于独立账号。

初始化默认只启用邮件登录链接和邮箱验证码。密码、WhatsApp 验证码、短信验证码、通行密钥、社交 OAuth 和企业 SSO 会保持隐藏，直到组织策略和必要凭据启用它们。

Passwordless Email Magic Link 和 OTP 请求在创建 challenge 时冻结 sign-up intent、服务端控制的 continuation、application client 和 invitation row ID。Social OAuth 邀请授权同样会在跳转上游 provider 前验证原始 capability,在一次性 state 中只持久化 invitation row ID,并在 callback 时忽略调用方控制的 token route。验证请求不能改写这些字段。原始 invitation capability 不会存入这些流程上下文;当 MFA 中断接受流程时,XID 使用绑定 Tenant、User、Session 和 invitation 的短期 signed continuation。

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

配置端点

GET /auth/config 返回该组织的公开 Hosted Auth 配置。提供商机密和已禁用的提供商不会返回给浏览器。

方式	显示时机
登录链接	已启用，并允许用于登录或创建用户。
邮箱验证码	已启用，并允许用于登录或创建用户。
手机验证码	WhatsApp 或短信提供商已配置、已启用，且允许登录或创建用户。
密码	密码策略会启用登录或用户创建。
社交 OAuth	提供商已启用、凭据已存在，并且策略允许此操作。
入站企业 SSO	域名发现会匹配已验证的组织域名。

标识符策略

组织可以要求邮箱标识、用户名标识或两者都要求。
允许和阻止的邮箱域名列表会在创建用户前生效。
需要企业连接时，强制 SSO 会隐藏本地登录方式。

WebAuthn 和 passkey 边界

通行密钥登录是主要 AAL2 认证。密码或 OTP 会话可通过 /auth/mfa/passkey/* 完成 MFA，且需要用户验证。
组织策略 attestationMode 在通行密钥注册时选择无、间接或直接企业证明。
WebAuthn 凭证参数公布 ES256、RS256 和 EdDSA。可同步通行密钥在 MFA 后仍属于 AAL2。
urn:xid:aal3 当前不会签发。WebAuthn UV 和 BE/BS 标志无法证明 NIST 所要求的不可导出硬件密钥；AAL3 请求会明确失败，目前最高只能映射到 AAL2。