FIDO Alliance

Passkey 중심적인

컨퍼런스 인증

시작하기

기존 웹 페이지 또는 애플리케이션이 있는 개발자가 FIDO 인증을 구현하려는 경우 애플리케이션에 두 가지 변경 사항을 적용해야 합니다: 1) 웹사이트 또는 모바일 애플리케이션의 로그인 및 등록 페이지를 FIDO 프로토콜을 사용하도록 수정합니다. 2) FIDO 등록 또는 인증 요청을 인증하기 위해 FIDO 서버를 설정합니다. 다음 두 섹션에서는 이러한 두 가지 변경 사항에 대해 수행해야 할 단계에 대해 간략하게 설명합니다.

등록 및 로그인 수정하기

애플리케이션에 이미 계정 등록 및 로그인 기능이 있다고 가정하면 등록 및 로그인 화면을 수정하는 것만큼이나 간단하게 FIDO 인증을 추가할 수 있습니다.

가장 먼저 결정해야 할 설계 사항은 첫 번째 요소 인증(비밀번호가 필요 없음)에 FIDO를 사용할지, 두 번째 요소 인증에 사용할지 여부입니다. 여기서 논의하기에는 사용 편의성, 플랫폼 가용성, 애플리케이션 유형, 위험 허용 범위 등 고려해야 할 사항이 너무 많지만, 좋은 소식은 첫 번째 요소에 FIDO를 사용하든 두 번째 요소에 사용하든 구현은 거의 동일하게 보인다는 점입니다.

등록

등록 웹 페이지에 FIDO를 통합하는 것은 올바른 등록 API 호출을 호출하는 것만큼이나 간단합니다. 각 FIDO 사양에 대한 등록 호출은 다음과 같습니다:

  • uaf: uaf_operation (
    iOS
    ,
    안드로이드
    ) – UAF 클라이언트 API 사양은 각각 안드로이드 인텐트 및 iOS X-콜백 체계를 작업 유형이 UAF_OPERATION으로 정의하며, UAF_OPERATION의 첫 번째 인수 중 하나는 인증자에게 등록을 수행하도록 지시합니다.
  • U2F:
    register()
     – U2F 사양은 브라우저에서 등록을 수행하기 위한 JavaScript API를 정의합니다.
  • FIDO2 / WebAuthn:
    navigator.credentials.create()
     – (FIDO2 프로젝트의 일부인) WebAuthn 사양은 브라우저에서 새 자격증명(일명 – 등록)을 만들기 위한 navigator.credentials.create() API를 정의합니다.

이러한 각 API 호출은 애플리케이션이 서버에서 챌린지(큰 난수)를 가져와서 해당 API 호출에 전달해야 합니다. 서버는 인증자에게 보낸 챌린지가 다시 받은 챌린지와 일치하는지 확인하므로, 애플리케이션에서 챌린지와 사용자 이름/사용자 계정을 추적하려면 일종의 세션 관리(예: 쿠키)가 필요할 수 있습니다. API 호출 후 API 호출의 결과 JSON 메시지는 서버로 다시 전송되며(일반적으로 서버에서 정의한 REST 엔드포인트를 통해), 서버는 등록 메시지의 챌린지, 서명, 출처 및 기타 주요 보안 특성을 검증합니다. 각 FIDO 사양에는 메시지의 유효성을 검사하기 위해 서버가 수행해야 하는 유효성 검사에 대한 설명이 있습니다:

서버는 등록의 성공 또는 실패 여부에 따라 성공 또는 실패로 응답합니다.

각 사용자의 계정에는 여러 개의 인증서가 등록되어 있을 수 있으므로 사용자가 여러 개의 인증서를 추가하고, 인증서를 구분할 수 있는 이름을 지정하고, 인증서를 분실하거나 도난당한 경우 인증서를 제거할 수 있도록 UX 흐름이 구성되어 있는지 확인하세요.

로그인

FIDO로 로그인하는 것은 등록과 매우 유사합니다. 각 FIDO 사양에 대한 등록 호출이 있는 것처럼, 유사한 로그인 API도 있습니다:

  • uaf: uaf_operation (
    iOS
    ,
    안드로이드
    ) – UAF 클라이언트 API 사양은 각각 안드로이드 인텐트 및 iOS X-콜백 체계를 작업 유형이 UAF_OPERATION으로 정의하며, 여기서 UAF_OPERATION의 첫 번째 인수 중 하나는 인증자에게 로그인을 수행하도록 지시합니다.
  • U2F:
    sign()
     – U2F 사양은 브라우저에서 어설션(일명 로그인)에 서명하기 위한 JavaScript API를 정의합니다.
  • WebAuthn:
    navigator.credentials.get()
     – WebAuthn 사양은 브라우저를 통해 자격 증명(일명 로그인)을 사용하기 위한 navigator.credentials.get() API를 정의합니다.

다시 말하지만, 등록 호출과 마찬가지로 로그인 API 호출에도 서버의 챌린지가 필요합니다. API에 따라 추가 정보가 필요할 수도 있습니다(예: WebAuthn은 이전에 등록한 계정의 ‘자격 증명 ID’를 요구할 수 있습니다). 일종의 세션 관리가 필요하다는 앞서 언급한 내용은 여기에도 적용되며, 나머지 API 흐름은 기본적으로 등록과 동일합니다. API 호출에 챌린지를 전달하고, 서버에 JSON을 반환하고, 서버의 성공/실패 응답을 기다리는 것입니다.

FIDO 서버 추가

FIDO 서버를 기존 인증 흐름과 통합하는 방법은 너무 많아서 여기서 모두 포괄적으로 다루기 어렵습니다. 예를 들어, FIDO 서버는 웹 또는 애플리케이션 서버와 통합될 수도 있고, 기존 IAM 프레임워크 내의 모듈로 제공될 수도 있으며, 독립형 서버일 수도 있고, 매우 광범위하고 복잡한 서비스의 경우 위의 모든 조합이 될 수도 있습니다. 또한 FIDO는 애플리케이션별 사용자 데이터 저장소(예: MySQL 또는 Mongo 데이터베이스)와 통합하거나, LDAP/ActiveDirectory와 통합하거나, OIDC(OpenID Connect) ID 공급자(IDP)를 통해 SSO를 제공할 수도 있습니다. 백엔드 인증 아키텍처와 사용 사례가 매우 다양하기 때문에 FIDO 서버 통합에 대한 모든 세부 사항을 설명하기는 어렵기 때문에 다음은 FIDO 서버 배포에 대한 일반적인 팁과 고려 사항입니다. 특정 서버 공급업체와 해당 공급업체의 문서에 기존 IAM 환경에 FIDO를 통합하는 방법에 대한 추가 정보가 추가되어야 합니다.

서버의 하드웨어와 소프트웨어를 설정하는 것 외에도 대부분의 서버 배포에 공통적으로 적용되는 몇 가지 단계가 있습니다:

  • 서버는 일반적으로 REST 엔드포인트를 사용하여 클라이언트와 통신합니다. 이를 위해서는 클라이언트와 통신하기 위한 적절한 방화벽 구성이 필요합니다. 앞서 언급했듯이 이러한 엔드포인트는 기존 애플리케이션(예: 웹 서버 또는 모바일 애플리케이션 서버)의 일부일 수도 있고, 마이크로 서비스 아키텍처 또는 ESB를 사용하여 메시지를 독립형 FIDO 서버로 라우팅할 수도 있습니다.
  • 서버는 https 통신이 필요하므로 https에 대한 유효한 TLS 인증서가 필요합니다(또는 앞에 TLS 터미네이터가 필요함).
  • 서버에는 등록 및 인증을 허용할 시기를 결정하기 위한 정책 구성이 있을 수 있습니다. 금융 또는 정부 기관의 경우, 여기에는 서비스에 액세스하는 인증자의 보안을 검증하기 위해 FIDO 메타데이터 서비스(MDS)를 사용하는 것이 포함될 수 있습니다.
  • 서버는 어떤 형태의 사용자 데이터 저장소(LDAP, ActiveDirectory, MySQL, MongoDB 등)와 통합되어야 합니다. 새로운 서비스의 경우, 각 사용자의 계정과 연결된 일종의 스토리지를 확보하기만 하면 됩니다. 기존 애플리케이션의 경우 데이터 스키마를 수정해야 하며, 일반적으로 사용자 계정과 등록할 인증자/자격증명 사이에 일대다 관계를 추가해야 합니다.

FIDO 서버 아키텍처 및 구성에 대한 도움말을 위한 추가 포럼은 여기 [커뮤니티 리소스 페이지 링크].