Vincent
Created: June 17, 2025
Updated: July 8, 2025
See the original glossary version in English here.
**증명(Attestation)**은 세 가지를 의미할 수 있습니다 (정확히는 다른 의미이지만, 구어체에서는 종종 혼용되어 사용됩니다):
첫째, 더 일반적으로 암호화 분야에서 증명은 한 당사자가 다른 당사자에게 문장을 암호학적으로 "증명"하는 용어입니다.
둘째, [WebAuthn]의 등록 단계에서 증명 객체가 [인증자]에 의해 생성되어 [신뢰 당사자]에게 반환됩니다. 이것은 다음 정보를 담고 있는 컨테이너 객체입니다:
fmt
)attStmt
- 아래 참조)authData
)다음 등록 프로세스 흐름은 WebAuthn에서 증명(객체)의 역할을 보여줍니다:
{ "root": { "id": "QFPlQVypLmmx71e0tmS3IfCFky0", "rawId": "QFPlQVypLmmx71e0tmS3IfCFky0", "response": { "attestationObject": { "fmt": "none", "attStmt": {}, "authData": { "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc", "flags": { "userPresent": true, "userVerified": true, "backupEligible": true, "backupStatus": true, "attestedData": true, "extensionData": false }, "counter": 0, "aaguid": "00000000-0000-0000-0000-000000000000", "credentialID": "QFPlQVypLmmx71eOtmS3IfCFky0", "credentialPublicKey": "pQECAyYgASFYIEa-lpSiQ4P...", "parsedCredentialPublicKey": { "keyType": "EC2 (2)", "algorithm": "ES256 (-7)", "curve": 1, "x": "Rr6WlKJDg8MlbIq9mmHQzk2p2c_s7QoNKr7yMa7I8pM", "y": "tAELYp7h3sYNjZZIZgHPYiaSzF×QVT18cgZ_7wm13Vw" } } }, "clientDataJSON": { "type": "webauthn.create", "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp", "origin": "https://passkeys.eu", "crossOrigin": false }, "transports": ["hybrid", "internal"], "publicKeyAlgorithm": -7 }, "authenticatorAttachment": "cross-platform" } }
위 스크린샷에서는 [AAGUID]와 증명서가 제공되지 않았습니다.
가장 중요한 속성에 대한 기술적 분석을 계속 읽어보세요.
[WebAuthn]에서 증명은 사용자 인증이 안전하고 투명하도록 보장합니다. 증명서를 사용하면 특정 [인증자]/기기에서 자격 증명이 생성되었는지 확인할 수 있습니다.
이러한 증명 유형은 증명 객체가 아닌 증명서를 나타냅니다. 이는 [신뢰 당사자]의 선호 사항으로 간주됩니다(따라서 [인증자]는 단지 선호 사항이므로 다르게 동작할 수 있습니다).
none
): 개인 정보 보호가 가장 중요하거나 동기화된 기기가 사용되는 경우,
이 유형은 기기에 대한 정보를 제공하지 않아 사용자의 개인 정보를 보호합니다. 이 값을
사용하는 또 다른 이유는 인증 기관(CA)으로의 왕복을 절약하기 위함일 수 있습니다. none
은
또한 기본값입니다.indirect
): [신뢰 당사자]는 증명을 받는 것을 선호하지만, 클라이언트가
증명서를 얻는 방법을 결정하도록 허용합니다. 클라이언트는 사용자의 개인 정보를 보호하기
위해 인증자가 생성한 증명서를 익명의 증명서로 대체할 수 있습니다.direct
): 가장 투명한 형태입니다. 여기서 [신뢰 당사자]는 인증자에게
증명서를 원한다고 알려, [신뢰 당사자]가 기기의 브랜드, 모델 및 기타 세부 정보를 포함한
상세 정보를 얻을 수 있도록 합니다. 가장 높은 투명성을 제공하지만, 특정 시나리오에서는
개인 정보 보호 문제를 야기하거나 동기화된 자격 증명에는 실제로 사용하기 어려울 수
있습니다.enterprise
): [신뢰 당사자]는 고유 식별 정보를 포함할 수 있는 증명서를
받기를 원합니다. 이 유형의 증명은 일반적으로 특정 기기/[인증자]를 추적하려는 기업이나
조직에서 사용됩니다. 웹 브라우저(사용자 에이전트)는 요청하는 당사자에 대해 특별히
허용하는 설정이 없는 한 이 상세한 증명을 제공해서는 안 됩니다. 설정이 허용하는 경우,
브라우저는 프로세스 시작 시 이 특정 유형의 증명이 요청되고 있음을 기기에 알려야 합니다.
그런 다음 브라우저는 기기의 고유 ID와 증명 증거를 받은 그대로 신뢰 당사자에게 전달해야
합니다.증명 객체는 많은 속성을 포함하고 있으며, 여기 몇 가지 선택된 속성에 대한 간략한 설명이 있습니다:
"attestationObject": { "fmt": "none", "attStmt": {}, "authData": { "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc", "flags": { "userPresent": true, "userVerified": true, "backupEligible": true, "backupStatus": true, "attestedData": true, "extensionData": false }, "counter": 0, "aaguid": "00000000-0000-0000-0000-000000000000", "credentialID": "QFPlQVypLmmx71eOtmS3IfCFky0", "credentialPublicKey": "pQECAyYgASFYIEa-lpSiQ4P...", "parsedCredentialPublicKey": { "keyType": "EC2 (2)", "algorithm": "ES256 (-7)", "curve": 1, "x": "Rr6WlKJDg8MlbIq9mmHQzk2p2c_s7QoNKr7yMa7I8pM", "y": "tAELYp7h3sYNjZZIZgHPYiaSzF×QVT18cgZ_7wm13Vw" } }
attestationObject는 새로 생성된 자격 증명, 공개 키 및 기타 관련 데이터에 대한 정보를 포함하는 [CBOR] 인코딩 객체입니다:
가독성을 위해 attStmt
가 비어 있던 위의 증명 객체와는 달리, 채워진 증명서는 다음과
같습니다.
{ "alg": -65535, "sig": "MBHX7qov53SWqqPYCrxE5fcoAeDI83a0DzVJ2-N1KI6IAaCGGvINAIFzTEn44F6giANKte-8yEMDZbvbgDG1weaRj7SqsVaTty-TEQ", "ver": "2.0", "x5c": [ "MIIFwDCCA6oIaK6tZ7M", "MIIG6zCCBNpG18-MCJrHyrpMT-ul7RgxE4dFxqcG59ftTXqJ1f-X_Lpo7K-d7OgKoQrUgzxgATz8YXtFAk3rE1cHXvW9W52V637eAihKn9-UKC0ijzVXrBGX4Iq1o1M0ZfR-tFoOn498xasMCTnharKiM562GBLVJtlvV3DMSLEBl5SfuGM-qYjQgTQknXccks9guCmNaN_b2fo1DisbufXfjM3DVaMqx7IJpSc3wAnxooMrAYGpPM" ], "pubArea": "AAEACwAw_c3Ousz865mUPx8O3w", "certInfo": "_1RDR4AXAniCekfsiDI" }
alg
: alg 속성은 인증자가 증명서에 서명하는 데 사용한 암호화 알고리즘 식별자를
나타냅니다.sig
: sig 속성은 인증자가 생성한 디지털 서명을 포함합니다. 이 서명은 증명서의 진위
여부를 확인하는 데 사용됩니다.ver
: ver 속성은 증명서 형식의 버전을 지정합니다.x5c
: x5c 배열은 증명 검증에 도움이 되는 인증 경로를 형성하는 하나 이상의 X.509
인증서를 포함합니다.pubArea
: pubArea 속성은 공개 키와 [인증자]의 특성에 대한 자세한 정보를 포함합니다.certInfo
: certInfo 속성은 일반적으로 신뢰할 수 있는 당사자에 의한 인증자 인증에 대한
정보를 포함합니다."clientDataJSON": { "type": "webauthn.create", "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp", "origin": "https://www.passkeys-debugger.io", "crossOrigin": false }
clientDataJSON
에 대한 자세한 내용은
해당 용어집 문서에서 읽어보세요.
"transports": [ "hybrid", "internal" ]
transports 속성은 인증자가 클라이언트와 통신할 수 있는 메커니즘을 나타냅니다. 몇 가지 일반적인 샘플 값 조합은 다음과 같습니다:
"transports": ["internal","hybrid"]
: [플랫폼 인증자](예: Face ID, Touch ID,
[Windows Hello]) 또는 교차 기기 인증([QR 코드] 및 블루투스
사용)을 통해 패스키를 사용할 수 있습니다."transports": ["internal"]
: [플랫폼 인증자](예: Face ID, Touch ID,
[Windows Hello])에서 패스키를 사용할 수 있습니다.transports
속성이 설정되지 않음: 아무런 표시도 없는 기본 동작입니다.[WebAuthn]의 증명(증명서)은 [인증자]의 진위 여부를 증명하기 때문에 중요합니다. 이를 통해 인증 프로세스가 신뢰할 수 있는 기기에서 수행되도록 보장하여 잠재적인 보안 위협으로부터 보호합니다.
Ben Gould
Head of Engineering
I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.
3,000명 이상의 개발자가 Corbado를 신뢰하고 패스키로 더 안전한 인터넷을 만듭니다. 질문이 있으신가요? 저희는 패스키에 대해 150개 이상의 블로그 게시물을 작성했습니다.
패스키 커뮤니티 참여하기네, 패스키는 기기 간에 동기화될 수 있으므로(예: iPhone에서 MacBook으로 [키체인]을 통해),
신뢰 당사자는 더 이상 어떤 증명된 기기가 앱이나 웹사이트에 실제로 로그인하는지 정확히
판단할 수 없습니다. 따라서 Apple과 Google은 동기화된 패스키에 대해서는 더 이상 증명서를
제공하지 않기로 결정했습니다. 그러나 신뢰 당사자의 UX를 개선하고 Apple 및 Google
생태계([iCloud 키체인] 및 [Google 비밀번호 관리자])의 패스키를 인식하고 표시할 기회를
제공하기 위해, WebAuthn 서버 설정에서 PublicKeyCredentialCreationOptions
에 대한 증명이
direct
또는 indirect
로 설정되어 있는 한 [AAGUID]는 계속 제공됩니다. 자세한 내용은 이
GitHub 이슈를 참조하세요.
웹사이트와 앱에 [패스키 인증]을 통합하고 사용자에게 훌륭한 패스키 UX를 제공하려면 다음을
고려해야 합니다. 대부분의 사용자가 Windows, [iOS],
macOS 또는 [Android] 운영 체제를 사용하는 시나리오를 주로 구축한다고 가정합니다. 또한
대부분의 패스키(Windows 제외)가 동기화된 패스키라고 가정합니다. iOS, macOS, [Android]
모두 더 이상 증명서를 보내지 않으므로 인증자의 실제 검증은 더 이상 사용되지
않습니다(Windows의 경우 아직 작동하며, 아마도 Windows가 아직
[Windows Hello]를 통해 동기화된 패스키를 제공하지 않기 때문일
것입니다). 그러나 계정 설정에서 더 나은 패스키 관리를 위해 [AAGUID]를 얻으려면 증명
선호도를 indirect
로 설정하는 것이 좋습니다. 이렇게 하면 증명서가 전송되거나(Windows)
전송되지 않는(iOS, macOS, Android) 동안에도 [AAGUID]를 얻을 수 있습니다.
[FIDO] 메타데이터 서비스는 다양한 [인증자]에 대한 메타데이터 저장소를 제공합니다. 증명 중에 이 서비스를 쿼리하여 [인증자]에 대한 세부 정보를 가져오고 검증하여 정확성을 보장하고 프로세스의 신뢰성을 높일 수 있습니다. [FIDO] 메타데이터 서비스는 증명 객체가 아닌 증명서를 확인합니다.
네, 직접 증명(증명서에서)은 기기에 대한 상세 정보를 제공하여 가장 높은 투명성을 제공하지만 특정 시나리오에서는 개인 정보 보호 문제를 야기할 수 있습니다. 증명 유형을 선택할 때 투명성의 필요성과 개인 정보 보호의 필요성을 평가하는 것이 중요합니다.
[WebAuthn]은 없음, 간접, 직접, 기업 등 다양한 유형의 증명 선호도를 제공합니다. [사용자
개인 정보]가 중요한 시나리오에서는 attestation=none
을 사용하여 기기에 대한 세부 정보를
제공하지 않음으로써 사용자의 개인 정보가 보호되도록 할 수 있습니다.
Table of Contents
Enjoyed this read?
🤝 Join our Passkeys Community
Share passkeys implementation tips and get support to free the world from passwords.
🚀 Subscribe to Substack
Get the latest news, strategies, and insights about passkeys sent straight to your inbox.