사용자 마이그레이션: 비밀번호 및 MFA 가져오기

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

​

가져오기 방식 두 가지

​

파일 가져오기

​

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명 단위 배치로 가져옵니다. 각 배치는 독립적으로 커밋됩니다.
• 애플리케이션당 한 번에 하나의 가져오기만 실행됩니다(그렇지 않으면 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을 반환합니다. 오류가 하나라도 있는 배치는 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

​

중복 및 기존 계정

• 이메일이 같은 행은 한 사람으로 합쳐집니다. 내용이 완전히 같은 행은 중복으로 집계합니다. 연결, 조직 또는 인증 앱이 더 많은 행은 병합됩니다.
• 한 사람에게 서로 다른 비밀번호 해시, 인증 앱 시크릿 또는 조직 역할이 두 개 이상 있으면 오류입니다. 두 사람이 같은 external_id 또는 제공자 subject를 주장하는 경우도 오류입니다.
• 같은 이메일의 계정이 이미 있고 이전 가져오기로 만들어진 계정이라면 해당 사용자는 건너뜁니다(already_imported). 사용자가 직접 가입한 계정이라면 identity_conflict 오류가 발생합니다. 가져오기는 기존 계정을 절대 변경하지 않습니다.

​

비밀번호

​

사용 가능한 비밀번호가 없는 사용자

​

소셜 연동, 인증 앱 및 조직

• 소셜 연동은 애플리케이션에 이미 구성된 제공자에 대해, 현재 클라이언트 ID 기준으로 유지됩니다. 이후 로그인할 때는 이메일 인증이 필요하지 않습니다. Google과 GitHub의 subject는 전역적으로 유효합니다. Apple의 subject는 개발자 팀별로, Microsoft의 subject는 앱 등록별로 구분됩니다. 따라서 기존 플랫폼이 같은 팀이나 등록 정보를 사용한 경우에만 해당 연동이 일치합니다. 구성되지 않은 제공자에 대한 연동은 social_unavailable로 집계되며 가져오지 않습니다.
• 인증 앱(TOTP 비밀 키: SHA-1, 6자리, 30초)은 암호화되어 저장됩니다. 가져온 사용자는 이를 2단계 인증 수단으로 사용해야 합니다. 이들에게는 복구 코드가 발급되지 않습니다.
• 아직 존재하지 않는 조직은 슬러그를 기준으로 생성됩니다.
• 패스키는 가져올 수 없습니다. 패스키는 기존 로그인 도메인에 속하므로, 사용자는 Didit으로 로그인한 뒤 새 패스키를 추가해야 합니다.

​

결과

​

전환하기 전에

• 가져온 각 비밀번호 형식으로 로그인,
• 사용 가능한 해시가 없는 사용자의 새 비밀번호 설정 이메일,
• 가져온 사용자의 소셜 로그인과 인증 앱 코드,
• 같은 파일을 두 번 실행하는 경우.