verified_claims 객체를 담은 ID 토큰이 포함됩니다.
이 프로필을 지원하는 모든 신뢰 당사자에서 같은 엔드포인트를 사용할 수 있으며, Auth0 post-login Action도 포함됩니다.
엔드포인트
모든 엔드포인트는 신원 확인 브리지 기본 URL 아래에 있습니다.
프로덕션과 샌드박스는 같은 엔드포인트를 사용합니다.
클라이언트 자격 증명과 연결된 애플리케이션이 환경을 결정합니다.
각 환경마다 해당 애플리케이션에 속한 별도의 클라이언트 자격 증명과 워크플로를 사용하세요.
시뮬레이션된 인증 결과는 Sandbox & Test Data를 참고하세요.
{base}/.well-known/openid-configuration의 디스커버리 문서에 모든 엔드포인트가 나열되어 있습니다.
클라이언트 인증에는
client_secret_basic 또는 client_secret_post를 사용합니다.
인가 코드 흐름에는 code_challenge_method=S256을 사용하는 PKCE가 필요합니다.
ID 토큰은 RS256으로 서명되며, JWKS 엔드포인트에서 검증하세요.
흐름
- 신뢰 당사자는 PKCE challenge,
state,nonce, 등록된redirect_uri,openid profile identity_assurance스코프, 그리고 검증을 요청할 클레임을 포함하여 인가 요청을POST /par로 푸시합니다. Didit는 60초 동안 유효한 일회용request_uri를 반환합니다. - 신뢰 당사자는 사용자의 브라우저를
GET /authorize?request_uri=...로 리디렉션합니다. Didit는 인증 세션을 생성하고 사용자를 호스팅 인증 흐름으로 보냅니다. - 사용자가 완료하면 Didit는 인증 결정을 평가하고, 추출된 신원 정보를 푸시된 클레임과 비교한 뒤, 일회용
code와 원래의state를 담아 신뢰 당사자의redirect_uri로 사용자를 돌려보냅니다. - 신뢰 당사자는
code_verifier와 함께POST /token으로 코드를 교환하고, 서명된 ID 토큰을 받습니다.
클레임 요청
비교할 클레임은 PAR 요청의 표준 OpenID Connectclaims 파라미터에 담아 보내세요.
given_name과 family_name을 모두 지원하며, 두 클레임 모두 항상 유사 일치 방식으로 비교됩니다.
verified_claims는 배열이며, 이는 Okta의 BYO IDV 프로필 및 아래의 ID 토큰 응답과 일치합니다.
ID 토큰
ID 토큰에는verified_claims 배열이 포함됩니다. assurance_level은 인증 세션이 승인되었고 요청된 모든 클레임이 검증된 문서와 일치한 경우에만 VERIFIED입니다.
그 외에는 FAILED입니다.
verification_process는 Didit 세션 ID이므로, 콘솔이나 세션 API에서 해당 인증 기록을 조회할 수 있습니다.
trust_framework가 IDV-DELEGATED이고 assurance_level이 VERIFIED인 경우에만 사용자를 인증된 것으로 처리하세요.
다른 조합은 모두 인증이 성공하지 않았음을 의미합니다.Okta 설정
Didit에 프로덕션 및 샌드박스 애플리케이션의 신원 확인 기능을 활성화하고, 각 애플리케이션을 해당 인증 워크플로와 연결하며, 각 Okta 테넌트의 정확한 콜백 URL을 등록해 달라고 요청하세요. 기존 애플리케이션이나 API 키만으로는 이 연동이 활성화되지 않습니다. Okta Admin Console에서 사용자 지정 신원 확인 벤더를 추가하고 아래 값을 입력하세요. Okta는IDV_STANDARD 유형과 ID_PROOFING 프로토콜을 가진 아이덴티티 공급자로 연동을 생성하며, 이후 Account Management Policy 규칙에서 이를 참조합니다.
프로덕션과 샌드박스는 각각의 자격 증명을 사용하는 별도의 신원 확인 연동으로 구성하세요.
두 환경 모두 위의 엔드포인트를 사용합니다.
이 흐름은 PKCE를 사용하지만 클라이언트 시크릿은 여전히 필요합니다.
이름을 지정해 만든 API 키는 이 연동에서 애플리케이션의 기본 API 키를 대신할 수 없습니다.
Didit가 클라이언트에 등록할 수 있도록 콜백 URL을 전달하세요.
Okta는 이를
{yourOktaOrgUrl}/idp/identity-verification/callback 형식으로 구성합니다.
Auth0 설정
Auth0에는 기본 제공되는 IDV 벤더 슬롯이 없으므로, 인증은 사용자를 같은 흐름으로 보내는 post-login Action에서 실행됩니다.DIDIT_IDV_BASE, DIDIT_CLIENT_ID, DIDIT_CLIENT_SECRET을 Action 시크릿으로 저장하고, https://{yourAuth0Domain}/continue를 Didit에 리디렉션 URI로 등록하세요.
Auth0는 로그인을 재개할 수 있도록
/authorize 리디렉션에 자체 state를 추가합니다. Didit는 이 state를 채택하여 /continue로 다시 돌려보내며, 이를 통해 Auth0가 트랜잭션을 완료할 수 있습니다. Auth0의 state를 PAR 본문에 전달할 필요는 없습니다. 리디렉션 시점까지 생성되지 않기 때문입니다.PKCE
code_verifier는 단일 app_metadata 필드가 아니라 로그인 트랜잭션별로(event.transaction.id를 키로 사용하여) 저장하세요.
사용자가 재시도하거나 로그인이 겹치면 공유 필드 하나가 덮어쓰여 토큰 교환이 invalid_grant로 실패합니다.오류
오류는 RFC 6749 및 RFC 9126을 따릅니다. 클라이언트 인증에 실패하면401과 함께 {"error": "invalid_client"}를 반환합니다. 만료되었거나 재사용된 request_uri 또는 인가 코드는 400과 함께 invalid_request 또는 invalid_grant를 반환합니다.
인가 코드, request_uri 값, 인증 세션은 모두 한 번만 사용할 수 있습니다.