호스팅 세션 (사용자 대면 흐름에 권장)
호스팅 세션은 대부분의 연동에서 권장되는 방식입니다. 세션을 생성하면 Didit이 사용자에게 제공할verification_url을 생성합니다. 사용자는 Didit의 최적화된 인터페이스에서 전체 인증 흐름을 완료하고, 결과는 webhook 또는 API를 통해 받게 됩니다.
작동 방식
1
세션 생성
서버가 워크플로 ID와 함께
POST /v3/session/을 호출합니다. Didit은 verification_url과 session_token을 반환합니다.2
사용자에게 제시
세션 토큰을 사용해 사용자를 리디렉션하거나, iframe으로 삽입하거나, 네이티브 SDK를 초기화합니다.
3
사용자가 인증 완료
사용자는 Didit의 최적화된 UI에서 안내에 따라 신분증 촬영, 라이브니스 감지 및 추가 단계를 진행합니다.
4
결과 수신
Didit은 인증 결정과 함께 서버로 webhook을 보내거나, 조회 API를 사용해 폴링할 수 있습니다.
세션을 권장하는 이유
세션을 사용할 때
- 사용자 온보딩 / KYC: 신규 사용자가 가입하면서 신원을 확인해야 하는 경우
- 연령 확인: 사용자가 최소 연령 요건을 충족하는지 확인하는 경우
- 재인증: 기존 사용자를 주기적으로 다시 인증하는 경우
- 생체 인증: 민감한 작업을 위해 사용자가 얼굴로 인증하는 경우
- 다단계 컴플라이언스: 신분증 + 라이브니스 감지 + AML + 전화번호를 한 번에 요구하는 흐름이 필요한 경우
- 최종 사용자가 직접 참여하여 상호작용하는 모든 시나리오
세션 endpoint
독립형 API (서버 간 처리용)
독립형 API를 사용하면 최종 사용자 UI 없이 서버에서 직접 개별 인증 기능을 호출할 수 있습니다. 데이터(이미지, 문서, 이름)를 보내면 구조화된 결과를 받습니다.작동 방식
1
데이터 전송
서버에서 필요한 데이터(이미지, 문서 또는 JSON 필드)와 함께 독립형 endpoint(예:
POST /v3/id-verification/)를 호출합니다.2
결과 수신
Didit이 요청을 동기적으로 처리하고, 응답에 구조화된 인증 결과를 반환합니다.
독립형 API를 사용하는 경우
사용 가능한 독립형 API
신원 및 문서
Document AI
생체 인식 및 얼굴
컴플라이언스 및 위험
은행 계좌 확인
기업 확인(KYB)
나란히 비교
둘 다 사용할 수 있나요?
예. 많은 팀이 두 방식을 함께 사용합니다.- 온보딩에는 세션 사용: 신규 사용자는 가입 중에 전체 호스팅 인증 흐름을 거칩니다.
- 지속적인 모니터링에는 독립형 AML 사용: 크론 작업이 승인된 모든 사용자를 매일 밤 업데이트된 감시 목록으로 다시 스크리닝합니다.
- 중복 탐지에는 독립형 얼굴 검색 사용: 새 세션이 승인되면 서버가 얼굴 검색을 호출해 중복을 확인합니다.
- 운영에는 독립형 신분증 인증 사용: 컴플라이언스 팀이 예외 사례 검토를 위해 문서를 수동으로 업로드합니다.