AI API 접근을 위한 생체 인증 강화: 권한을 개인에게 연결 (KO)

온보딩 시의 인증은 계정을 생성한 사람을 증명합니다. 하지만 현재 누가 계정을 사용하고 있는지는 증명하지 못합니다.

이러한 간극은 대부분의 제품에서 일반적이며, AI 플랫폼에서는 계정 뒤의 자산이 모델 접근, 크레딧, 할당량이기 때문에 중요한 결과를 초래합니다. API 키는 베어러 토큰입니다. 즉, 이를 소유한 사람이 계정의 소유자입니다. 키는 팀 내에서 공유되거나, 저장소에 붙여넣어지거나, 판매되거나, 탈취될 수 있습니다. 온보딩 후 6개월이 지나면 "이 계정은 인증되었습니다"라는 말은 과거에 대한 진술일 뿐입니다.

생체 인증은 이러한 간극을 메웁니다. 권한 있는 작업이 발생하는 순간 실제 사람을 재확인합니다. 문서도, 암호도 필요 없으며, 2초 이내에 $0.10의 비용으로 인증됩니다.

주요 요점

• 온보딩 인증은 스냅샷입니다. 생체 인증은 중요한 순간의 확인입니다.
• 사용자의 최초 인증 시 이미 저장된 인물 사진과 대조하여 라이브니스 및 얼굴 일치 확인. 문서나 암호는 필요 없습니다.
• 세션 전용입니다. 전용 /v3/biometric-auth/ 엔드포인트는 없습니다. workflow_type=BIOMETRIC_AUTHENTICATION을 사용하는 세션을 통해 실행됩니다.
• 중요한 구현 세부 사항: 사용자의 최초 인증과 동일한 vendor_data를 사용해야 합니다. 그렇지 않으면 저장된 얼굴을 검색할 수 없습니다.
• 올바른 트리거: 할당량 증가, 크레딧 부여, 새 API 키 발급, 티어 업그레이드, 권한 있는 팀원 추가, 트래픽 레이어의 모든 행동 경고.
• 인증당 $0.10, 성공 시 지불, 2초 미만 소요.

AI 플랫폼에 재인증이 필요한 이유

세 가지 실패 모드는 온보딩 스냅샷이 불충분하다는 것을 보여줍니다.

키 공유 및 재판매. 인증된 개발자에게 발급된 키는 어디든 갈 수 있습니다. 계정은 인증된 상태로 유지되지만, 이를 사용하는 사람은 인증된 사람이 아닙니다. 이는 합법적으로 인증된 계정이 파밍 네트워크의 진입점이 되는 메커니즘이며, 온보딩만 확인하는 어떤 제어에도 보이지 않습니다.

계정 탈취. 자격 증명이 피싱되거나 스터핑되어 공격자가 확립된 평판과 상향된 한도를 가진 인증된 계정을 상속받습니다. 인증된 계정은 덜 매력적인 대상이 아니라 더 매력적인 탈취 대상입니다.

사후 권한 에스컬레이션. 1월에 적당한 접근 권한으로 인증된 계정이 8월에 50배의 할당량 증가를 요청합니다. 1월의 인증은 8월의 요청과 아무 관련이 없습니다.

이 세 가지 경우 모두 계정의 인증 상태는 변경되지 않으며, 그 뒤의 사람은 당신이 생각하는 사람이 아닙니다. 암호, 일회성 코드 또는 세션 토큰은 이러한 경우를 구별할 수 없습니다. 왜냐하면 이들 모두는 자격 증명을 합법적으로 소유한 공격자이기 때문입니다. 생체 인식 확인만이 중요한 질문을 합니다. 지금 여기에 있는 사람이 인증된 사람입니까?

작동 방식

생체 인증은 일반적인 신원 확인 흐름과 동일한 LivenessV3 및 FaceMatchV3 구성 요소를 재사용합니다. 유일한 차이점은 참조 이미지가 어디에서 오는지입니다. 새로 제출된 문서의 인물 사진 대신, 사용자의 이전 인증에서 이미 저장된 인물 사진을 사용합니다.

이것이 문서가 필요 없는 이유이며, 일반적인 제품 흐름에 배치할 만큼 빠르고 저렴한 이유입니다.

세션 전용입니다.

전용 /v3/biometric-auth/ 엔드포인트는 없습니다. 인증은 해당 워크플로가 구성된 세션을 통해 제공됩니다(workflow_type=BIOMETRIC_AUTHENTICATION). API 참조에서 독립형 엔드포인트를 찾고 있다면, 찾을 수 없는 이유가 여기에 있습니다.

흐름

1. 콘솔에서 BIOMETRIC_AUTHENTICATION 유형의 워크플로를 구성하고 workflow_id를 기록합니다.
2. 세션을 생성합니다.

curl -X POST 'https://verification.didit.me/v3/session/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "workflow_id": "YOUR_BIOMETRIC_AUTH_WORKFLOW_ID",
    "vendor_data": "acct_8842",
    "callback": "https://yourplatform.example/auth/complete"
  }'

1. 반환된 세션을 통해 사용자를 안내합니다. 호스팅되거나, 무료 SDK 중 하나와 함께 임베드될 수 있습니다.
2. 결정을 가져옵니다.

curl -X GET 'https://verification.didit.me/v3/session/{sessionId}/decision/' \
  -H 'x-api-key: YOUR_API_KEY'

또는 session.status.updated를 구독하고 웹훅을 받습니다.

통합을 방해하는 한 가지 세부 사항

사용자의 최초 인증과 동일한 vendor_data를 사용하십시오.

이 값은 Didit이 저장된 인물 사진을 검색하여 일치시키는 방법입니다. 새롭거나 다른 vendor_data는 비교할 저장된 얼굴이 없다는 것을 의미하며, 흐름은 요청한 작업을 수행할 수 없습니다. 저장된 참조를 의도적으로 재정의해야 하는 경우 portrait_image를 명시적으로 전달하지만, 일반적인 경로는 계정당 안정적인 vendor_data를 온보딩 시 설정하고 영원히 재사용하는 것입니다.

이것이 vendor_data를 처음부터 자체 스키마에서 일급 식별자로 취급해야 하는 이유입니다. 또한 얼굴 검색 결과가 계정에 깔끔하게 매핑되는 이유이기도 합니다.

결과 읽기

결과는 liveness_checks 및 face_matches에 도착합니다. 둘 다 항상 배열이며(단일 객체가 아님), 각 항목에는 node_id가 있어 다중 인스턴스 워크플로가 단계를 명확히 할 수 있습니다. 각 항목은 해당 단계에서 데이터가 생성될 때까지 null입니다.

경고에는 LOW_LIVENESS_SCORE, 얼굴 공격 경고, 블랙리스트 일치, 낮은 얼굴 일치 유사성이 포함됩니다. 임계값 및 거부 조치는 구성 가능하므로, 일반적인 할당량 증가보다 대규모 크레딧 부여에 더 엄격한 기준을 적용할 수 있습니다.

어떤 상황에서 단계별 인증을 트리거해야 하는가

이 제어의 가치는 거의 전적으로 트리거 설계에 달려 있습니다. 너무 많으면 불편을 초래하고, 너무 적으면 중요한 순간에 작동하지 않습니다.

접근 권한 에스컬레이션 — 할당량 증가, 크레딧 부여, 새 API 키 발급, 티어 업그레이드, 민감하게 취급하는 기능 티어로 이동.

계정 변경 — 새로운 권한 있는 팀원, 청구 소유자 변경, 지급 대상 변경, 암호 또는 MFA 재설정.

행동 경고 — 가장 가치 있는 트리거. 자체 트래픽 레이어가 집중적인 쿼리 또는 증류 형태의 패턴에 대해 계정에 플래그를 지정할 때, 생체 인식 단계별 인증은 트래픽 레이어가 할 수 없는 한 가지 질문을 합니다. "인증된 사람이 여전히 이 계정을 운영하고 있는가?" 통과하면 해석이 좁혀집니다. 실패 또는 포기 자체도 강력한 신호입니다.

연결 신호 — DEVICE_RECOVERED_HIGH_CONFIDENCE를 포함하는 세션 또는 기존 인증된 사용자와 일치하는 얼굴은 계정이 무엇을 요청하는지에 관계없이 단계별 인증을 받을 자격이 있습니다.

휴면 상태 + 에스컬레이션 — 몇 달 동안 조용했던 계정이 갑자기 대규모 증가를 요청하는 경우. 휴면 상태만으로는 안 되며, 두 가지의 조합입니다.

왜 그냥 암호나 코드를 요구하지 않는가?

모든 기존 요소는 베어러 자격 증명이며, 여기서의 위협 모델은 자격 증명을 소유한 공격자이기 때문입니다.

일회성 코드는 파일에 있는 전화번호나 주소로 전송됩니다. 이는 탈취 후 공격자가 제어하며, 합법적인 키 공유자는 단순히 전달합니다. 암호는 문자열에 대한 지식을 증명합니다. 하드웨어 키는 개체의 소유를 증명하며, 이는 키와 함께 넘겨질 수 있습니다.

라이브니스 확인된 얼굴 일치는 특정 사람이 현재 이 순간에 존재한다는 것을 증명합니다. 권한을 개인에게 바인딩하는 데 있어서, 이것이 실제 질문에 답하는 유일한 요소입니다. $0.10의 비용과 2초 미만의 시간으로, 비상 상황을 위해 아껴두지 않고 실제 트리거에 사용할 만큼 저렴합니다.

하지 않는 일도 언급할 가치가 있습니다. 계정 뒤의 사람을 재인증하는 것은 모델 추출을 방지하지 않으며 감지하지도 않습니다. 인증된 개발자는 여전히 자신이 가진 접근 권한을 오용할 수 있습니다. 이것은 "이 계정은 한 번 인증되었습니다"와 "이 사람이 지금 여기에 있습니다" 사이의 좁고 실제적인 간극을 메웁니다. 모델 수준 출력 제어 및 의미론적 트래픽 감지는 별도의 계층으로 남아 있으며, 이는 귀하의 책임입니다.

사용 사례

• 할당량 에스컬레이션, 크레딧 부여 및 키 발급을 사용자 확인 뒤에 두는 AI API 플랫폼.
• 에이전트에게 새로운 기능이 부여되거나 지출 한도가 상향되기 전에 단계별 인증을 요구하는 에이전트 및 자동화 제품.
• 고가치 이체 또는 지급 대상 변경 전에 재인증하는 금융 서비스.
• 가장 흔한 계정 탈취 보상인 지급 방법 변경 전에 판매자를 재확인하는 마켓플레이스.
• 대부분의 계정 보안 설계에서 가장 약한 고리인 지식 기반 질문 대신 생체 재인증을 사용하는 복구 흐름이 있는 모든 플랫폼.

자주 묻는 질문

사용자가 문서를 다시 제출해야 하나요?

아니요. 그것이 핵심입니다. 검사는 사용자의 최초 인증에서 이미 저장된 인물 사진과 대조하여 실행됩니다. 라이브니스와 얼굴 일치, 문서 없음.

사용자가 Didit으로 인증된 적이 없다면요?

그렇다면 저장된 인물 사진이 없으며, 인증할 대상도 없습니다. 생체 인증은 재인증 기본 기능입니다. 동일한 vendor_data로 이전 인증이 이루어졌다고 가정합니다.

얼마나 걸리나요?

2초 미만의 추론 시간. 사용자 입장에서는 셀카 한 장과 잠깐의 시간입니다.

우리 자체 인터페이스 내에서 실행할 수 있나요?

예. 웹, iOS, Android, React Native 및 Flutter SDK는 모두 무료이며, 화이트 라벨($0.20)은 Didit 브랜딩을 제거합니다.

누군가 계정 소유자의 사진이나 비디오를 들고 있다면요?

그것이 라이브니스 감지의 목적입니다. Didit의 수동 라이브니스는 iBeta 레벨 1 프리젠테이션 공격 감지 평가를 받았으며, 얼굴 공격 경고는 경고에 표시됩니다. 임계값은 구성 가능합니다.

비용은 얼마인가요?

인증당 $0.10, 성공 시 지불, 최소 금액 없음.

모든 로그인에 이것이 필요해야 하나요?

아니요. 로그인은 잘못된 트리거입니다. 계속해서 발생하지만 대부분 의미가 없습니다. 잘못될 경우 비용이 많이 들고 빈도가 낮은 권한 에스컬레이션 및 경고에 연결하십시오.

시작할 준비가 되셨나요?

하나의 워크플로를 구성하고, 이를 에스컬레이션 지점에 연결한 다음, 모든 곳에서 재사용하십시오.

• 문서 읽기 — 생체 인증 개요 및 세션 API.
• 제품 보기 — 사용자 확인.
• 가격 확인 — 인증당 $0.10, 성공 시 지불, 최소 금액 없음.
• 무료 시작 — business.didit.me, 한 달에 500건의 KYC 인증 무료.