ホスト型認証

統合フロー

XID はエンドユーザー登録とログインを別々の製品として提供しません。Hosted Auth は同じ識別子ステップから開始し、Organization のポリシーとアカウントの状態に基づいてログインまたはユーザー作成を決定します。ゲストまたは資格情報による intent=sign-up のサインアップでは、Email、Organization name、URL slug を指定してトップレベルの Tenant を作成します。ゲストの Email はアカウントアドレスを予約せず保留状態となります。新しい所有者は Console のデータを読み取れますが、最初の業務変更を行う前にその Email を確認します。別の Tenant で同じ Email を使っても、別のアカウントとして扱われます。

初期設定ではメールリンクと Email OTP のみが有効です。パスワード、WhatsApp OTP、SMS OTP、パスキー、ソーシャル OAuth、エンタープライズ SSO は、組織ポリシーと必要な認証情報で有効になるまで非表示です。

パスワードレスのメールマジックリンクおよび OTP リクエストでは、チャレンジ作成時にサインアップの意図、サーバー管理の継続先、アプリケーションクライアント、招待行 ID を固定します。Social OAuth の招待認可でも、外部プロバイダーへリダイレクトする前に元のケイパビリティを検証し、1 回限りの状態には招待行 ID だけを保存し、コールバックではクライアント管理のトークンルートを無視します。検証時にこれらのフィールドを書き換えることはできません。元の招待ケイパビリティがこれらのフローコンテキストに保存されることはありません。MFA によって受諾が中断される場合、XID は Tenant、ユーザー、セッション、招待にバインドされた短時間有効な署名付き継続トークンを使用します。

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 設定を返します。プロバイダーのシークレットと無効なプロバイダーはブラウザーに返されません。

識別子ポリシー

• 組織はメール識別子、ユーザー名識別子、またはその両方を要求できます。
• 許可およびブロックされたメールドメインの一覧は、ユーザー作成前に適用されます。
• エンタープライズ接続が必要な場合、SSO 強制によりローカル方式は非表示になります。

WebAuthn と passkey の境界

• パスキーサインインは主要な AAL2 認証です。パスワードまたは OTP セッションは、ユーザー検証が必要な /auth/mfa/passkey/* で MFA を完了できます。
• 組織ポリシー attestationMode は、パスキー登録時に none、indirect、direct のエンタープライズアテステーションを選択します。
• WebAuthn クレデンシャルパラメータは ES256、RS256、EdDSA を公開します。同期可能なパスキーは MFA 後も AAL2 のままです。
• urn:xid:aal3 は現在発行されていません。 WebAuthn UV および BE/BS フラグは、NIST が要求するエクスポート不可能なハードウェア キーを証明するものではありません。 AAL3 リクエストは明示的に失敗し、現在の最大マッピングは AAL2 です。