인증(Authentication): 최종 사용자 로그인, 패스키 및 세션

인증은 고객을 귀하의 애플리케이션에 로그인시킵니다. 이는 Didit 콘솔에 로그인하거나 Didit 개발자 계정을 만드는 것과 별개입니다. 또한 사람의 신원을 확인하는 것과도 별개입니다. 인증만 단독으로 사용하거나, 신원 확인 및 거래 모니터링과 함께 사용할 수 있습니다. 로그인한다고 신원 확인이 승인되거나 결제가 허가되지는 않습니다. 각 제품의 고유한 결과에 따라 백엔드가 그러한 결정을 내립니다.

​

작동 방식

각 애플리케이션은 고유한 로그인 오리진과 고유한 토큰 발급자를 가집니다. 라이브 애플리케이션과 샌드박스 애플리케이션은 분리되어 있습니다. 오리진, 설정, 아이덴티티가 각각 분리되어 있습니다. 흐름은 PKCE(S256만 해당)를 사용하는 OAuth 2.0 인가 코드 방식입니다.

1. 앱이 redirect_uri, state, code_challenge, code_challenge_method=S256을 포함하여 {origin}/sign-in을 엽니다.
2. 호스팅 페이지가 설정한 인증 방식을 사용하여 사용자를 로그인 또는 가입시키며, 필요한 2단계 인증도 포함됩니다.
3. 브라우저가 code와 state를 담아 사용자의 redirect_uri로 돌아갑니다.
4. 앱이 POST {origin}/token/에서 코드를 교환하여 액세스 토큰, ID 토큰, 리프레시 토큰을 받습니다.

토큰 계약은 토큰 및 JWKS를, 각 인증 방식은 로그인 방식을 참조하십시오.

​

플랫폼 선택

​

애플리케이션 준비

1. 애플리케이션의 인증 기능을 켜도록 Didit에 요청하십시오. 먼저 샌드박스 애플리케이션에서 테스트하십시오.
2. 정확한 리디렉션 URL(최대 50개)과 런타임 API를 호출하는 브라우저용 allowed_origins(최대 50개)를 등록하십시오.
3. 제공하려는 로그인 방식을 활성화하십시오. Didit ID Wallet은 항상 켜져 있습니다.
4. 세션 및 비밀번호 설정을 선택하십시오(아래 참조).
5. 프로덕션 환경에 배포하기 전에 가입, 로그인, 비밀번호 찾기, MFA, 세션 만료, 로그아웃을 테스트하십시오.

패스키는 해당 오리진에 종속됩니다. 나중에 맞춤 도메인을 활성화하면 사용자는 패스키를 다시 등록해야 합니다.

​

리디렉션 URL

Didit은 사용자를 등록된 주소로만 리디렉션합니다. 콘솔의 Authentication > Security and sessions > Redirect URLs and allowed origins에서 주소를 등록하십시오. 로그인 요청의 redirect_uri는 등록된 URL과 문자 단위로 정확히 일치해야 합니다. 스킴, 호스트, 포트, 경로, 쿼리가 모두 같아야 합니다. 포트가 다르거나, 끝에 슬래시가 있거나, 대소문자가 다르면 다른 주소로 취급됩니다. 와일드카드, 프래그먼트, URL에 포함된 자격 증명, 사용자 지정 스킴은 거부됩니다. 주소가 등록되어 있지 않으면 Didit은 절대 그 주소로 리디렉션하지 않습니다. {origin}/sign-in은 무엇을 어디에 등록해야 하는지 설명하는 페이지와 함께 400을 반환하고, POST {origin}/authorize/는 400 {"error": "invalid_redirect_uri"}를 반환합니다.

​

로컬 개발

샌드박스 애플리케이션으로 자신의 컴퓨터에서 테스트하십시오.

1. 포트를 포함하여 콜백을 등록하십시오. 예: http://localhost:3000/auth/callback.
2. 브라우저 코드가 런타임 API를 호출하는 경우(예: POST {origin}/token/에서 코드 교환), Allowed origins에도 오리진을 추가하십시오. 예: http://localhost:3000. 경로와 끝 슬래시는 넣지 마십시오.
3. pk_test_... 키를 사용하여 샌드박스 오리진 https://<slug>.sandbox.auth.didit.me에서 로그인을 시작하십시오.

localhost, 127.0.0.1, [::1]은 서로 다른 주소이며, 포트마다 별도의 주소입니다. 사용하는 각 주소를 모두 등록하십시오. 라이브 애플리케이션은 http://를 절대 허용하지 않습니다. 프로덕션 환경에 배포하기 전에 라이브 애플리케이션에 프로덕션 https:// 콜백을 등록하십시오.

​

애플리케이션 설정

이 설정은 콘솔에서 관리하거나, write:authentication 권한이 있는 승인된 콘솔 세션으로 관리합니다.

​

여러 제품에서 한 사람 유지하기

모든 신원에는 vendor_data 값이 포함됩니다. 이 값은 사람을 가져올 때 제공한 external_id이거나, 그렇지 않은 경우 Didit 신원 ID입니다. 이 값은 액세스 토큰, ID 토큰, GET session/에 나타납니다. 인증 세션을 생성하고 거래를 제출할 때 같은 값을 vendor_data로 사용하십시오. 그러면 Authentication 이벤트가 콘솔에서 해당 사람의 인증 및 거래와 동일한 사람의 기록에 추가됩니다. 이벤트 및 webhook을 참조하십시오. vendor_data는 검증된 토큰에서 백엔드가 도출해야 하며, 확인되지 않은 브라우저 필드에서 가져와서는 안 됩니다. 어떤 조합이든 공통 연동 프롬프트를 사용하십시오. 로그인 시 실행되는 정책은 봇 방지를 읽어 보십시오.