ユーザー移行：パスワードとMFAのインポート

https://apx.didit.me/auth/v2/organizations/{org_id}/applications/{application_id}/authentication/

​

2つのインポート方法

​

ファイルのインポート

​

1. アップロード

curl --fail-with-body "${MANAGEMENT_BASE}import-jobs/" \
  -H "Authorization: Bearer $CONSOLE_ACCESS_TOKEN" \
  -F file=@users.csv \
  -F passwords=import \
  -F keep_social=true \
  -F keep_verified=true \
  -F keep_mfa=true \
  -F keep_ids=true

​

2. ドライランを確認する

​

3. インポートを開始する

• ユーザーは1,000人ずつのバッチでインポートされます。各バッチは個別にコミットされます。
• 1つのアプリケーションで同時に実行できるインポートは1件のみです(それ以外の場合はimport_running)。
• 中断されたインポートは、最後にコミットされたバッチの後から再開されます。
• すでにインポートされたユーザーはスキップされるため、同じファイルを再度実行できます。
• インポートを開始した人には、インポートが完了または停止したときにメールが届きます。

​

バッチでのインポート

{
  "rows": [
    {
      "email": "user@example.com",
      "external_id": "user-1234",
      "email_verified": true,
      "display_name": "Example User",
      "password_hash": "$2b$12$...",
      "social": [{ "provider": "google", "subject": "1234567890" }],
      "organizations": [{ "slug": "acme", "name": "Acme", "role": "admin" }]
    }
  ],
  "dry_run": true,
  "idempotency_key": "migration-batch-0001"
}

• ドライランは結果とともに200を返し、何も書き込みません。
• dry_run: falseの場合、インポートに成功すると201を返します。エラーを1件でも含むバッチは400を返し、誰もインポートされません。
• コミット済みのリクエストを同じキーで繰り返すと、記録済みの結果が返されます。同じキーで内容が異なる場合は400 {"idempotency_key": "different_payload"}が返されます。
• Firebaseのパラメーターはfirebaseオブジェクト{signer_key, salt_separator, rounds, mem_cost}に指定します。
• GET imports/はコミット済みのバッチを一覧表示します。

​

ファイル形式

​

JSON

​

CSV

email,external_id,email_verified,password_hash,google_id,organization_slug,organization_role
user@example.com,user-1234,true,$2b$12$...,1234567890,acme,admin

​

重複と既存のアカウント

• 同じメールアドレスの行は1人のユーザーとしてまとめられます。まったく同じ行は重複としてカウントされます。リンク、組織、認証アプリが追加されている行はマージされます。
• 1人のユーザーに対して2つの異なるパスワードハッシュ、認証アプリのシークレット、または組織での役割が存在する場合はエラーになります。同じexternal_idまたはプロバイダーのsubjectが2人のユーザーに紐付けられている場合もエラーです。
• そのメールアドレスのアカウントがすでに存在し、それが以前のインポートで作成されたものである場合、そのユーザーはスキップされます(already_imported)。ユーザーが自分でサインアップしていた場合は、identity_conflictエラーになります。インポートによって既存のアカウントが変更されることはありません。

​

パスワード

​

使用可能なパスワードがないユーザー

​

ソーシャル連携・認証アプリ・組織

• ソーシャル連携は、アプリケーションですでに設定済みのプロバイダーについて、現在のクライアントIDのもとで保持されます。これにより、再訪時のサインインではメールによる確認が不要になります。GoogleとGitHubのsubjectはグローバルです。Appleのsubjectは開発者チームごと、Microsoftのsubjectはアプリ登録ごとに異なるため、これらの連携は以前のプラットフォームが同じチームまたは同じアプリ登録を使用していた場合にのみ一致します。設定していないプロバイダーへの連携はsocial_unavailableとしてカウントされ、インポートされません。
• 認証アプリ（TOTPシークレット: SHA-1、6桁、30秒）は暗号化して保存されます。インポートされたユーザーは、これを第2要素として使用する必要があります。リカバリーコードは付与されません。
• まだ存在しない組織は、そのslugをもとに作成されます。
• パスキーはインポートできません。パスキーは以前のサインインドメインに紐づいているため、ユーザーはDiditでサインインした後に新しいパスキーを追加します。

​

結果

​

切り替える前に

• インポートする各パスワード形式でのサインイン
• 使用可能なハッシュがないユーザーへの新しいパスワード設定メール
• インポートしたユーザーのソーシャルサインインと認証アプリのコード
• 同じファイルを2回実行した場合の動作