TsgcWSAPIServer_WebAuthn
OpenSSL 3만 해당.
소개
TsgcWSAPIServer_WebAuthn 구성 요소는 WebAuthn Relying Party 서버를 구현하기 위한 간단하지만 강력한 솔루션을 제공하여 웹 애플리케이션에서 비밀번호 없는 인증을 가능하게 합니다. WebAuthn 애플리케이션은 서버 측 등록 및 인증을 처리하는 WebAuthn 서버와 일반적으로 javascript 애플리케이션인 클라이언트 측 애플리케이션으로 구성됩니다.
WebAuthn은 보안 연결(SSL/TLS)의 사용을 요구하므로 OpenSSL 라이브러리를 배포하고 서버와 함께 구성해야 합니다.
OpenSSL 3.0.0+ API만 지원됩니다. 따라서 이전 OpenSSL 버전은 작동하지 않을 수 있습니다.
구성
TsgcWSAPIServer_WebAuthn은 Server 속성을 사용하여 HTTP 서버, TsgcWebSocketHTTP_Server 또는 TsgcWebSocketServer_HTTPAPI에 연결되어야 합니다. 등록 및 인증 옵션을 처리할 서버 엔드포인트와, 지원되는 알고리즘, origin 등의 WebAuthn 옵션을 구성할 수 있습니다.
Endpoints Options
여기에서 WebAuthn을 인증자로 사용하기 위한 HTTP/JavaScript 요청을 처리할 서버 엔드포인트를 구성할 수 있습니다. 구성 요소는 이미 기본 엔드포인트로 구성되어 있지만, 필요에 맞게 모두 변경할 수 있습니다.
- AuthenticationOptions: 기본값은 /sgcWebAuthn/Authentication/Options입니다.
- AuthenticationVerify: 기본값은 /sgcWebAuthn/Authentication/Verify입니다.
- RegistrationOptions: 기본값은 /sgcWebAuthn/Registration/Options입니다
- RegistrationVerify: 기본값은 /sgcWebAuthn/Registration/Verify입니다
- Webauthn: 기본적으로 사용되는 javascript 라이브러리를 포함합니다. 이 속성을 비활성화하고 자체 webauthn 라이브러리를 사용할 수 있습니다.
- Test: 기본적으로 비활성화되어 있으며, WebAuthn 기능을 테스트하는 데만 사용하십시오.
예: 서버가 도메인 www.test.com에서 수신 중인 경우, 기본적으로 인증 옵션에 대한 요청은 http://www.test.com/sgcWebAuthn/Authentication/Options가 됩니다.
WebAuthn Options
이 속성에서 WebAuthn 서버 구성 요소의 주요 옵션을 구성할 수 있습니다.
- RelyingParty: 서버의 DNS 이름을 정의해야 하는 필수 속성입니다. 예: 서버가 www.test.com 도메인에서 실행 중인 경우 이 속성을 "www.test.com"으로 설정하십시오.
WebAuthn은 origin을 사용하여 same-origin 정책 제약 조건을 적용하며, 이는 피싱 및 cross-site 공격을 방지하는 데 필수적입니다. WebAuthn 등록 및 인증 프로세스 중에 origin은 브라우저와 authenticator에 의해 엄격하게 검증됩니다.
- Origins: 요청이 다른 origin에서 올 수 있는 경우, Origin 속성을 사용하여 추가 origin을 설정하십시오. 예제: 요청이 login.test.com과 www.test.co.uk에서 올 수 있는 경우, Origins 속성을 https://login.test.com 및 https://www.test.co.uk 값으로 구성하십시오
- TopOrigins: 일반적으로 WebAuthn은 호출 프레임(즉, navigator.credentials.create() 또는 navigator.credentials.get()을 호출하는 프레임)의 origin에 의존합니다. 그러나 웹 페이지는 최상위 페이지와 다른 origin에서 올 수 있는 iframe에 포함될 수 있습니다. 이는 악용이나 클릭재킹 스타일 공격의 가능성을 열어줍니다. 이를 완화하기 위해 WebAuthn Level 2 사양은 TopOrigins를 정의할 수 있는 TopOrigin을 도입합니다.
WebAuthn에서 crossOrigin은 WebAuthn 작업이 최상위 브라우징 컨텍스트와 다른 origin에서 임베드된 iframe과 같은 교차 origin 컨텍스트에서 수행되는지 여부를 나타내는 boolean 매개변수입니다.
이 매개변수는 브라우저와 인증자가 임베디드 환경에서 인증 요청을 안전하게 처리하도록 돕기 위해 도입되었으며, 이는 최신 웹 애플리케이션에서 일반적인 시나리오입니다.
- AllowCrossOrigins: true인 경우, 크로스 오리진 iframe(예: https://app.example.org 페이지에 포함된 https://auth.example.com의 iframe)에서 만들어진 요청이 허용됨을 나타냅니다. 기본적으로 비활성화되어 있습니다.
WebAuthn은 공개 키 자격 증명 생성 및 검증을 위한 다양한 암호화 알고리즘을 지원합니다. 이 알고리즘들은 자격 증명 등록(navigator.credentials.create() 사용) 및 인증(navigator.credentials.get() 사용) 중에 사용되며, 비대칭 키 쌍을 사용하여 챌린지의 안전한 서명 및 검증을 보장합니다. 서버는 기본적으로 가장 일반적인 알고리즘인 ES256 및 RS256로 구성되어 있습니다. Algorithms 속성에서 어떤 알고리즘을 지원할지 언제든지 변경할 수 있습니다. 다음 알고리즘이 지원됩니다:
- ES256
- ES384
- ES512
- RS256
- RS384
- RS512
- PS256
- PS384
- PS512
- RS1
- EdDSA
WebAuthn에서 attestation은 선택적 메커니즘으로, authenticator(예: 디바이스 또는 보안 키)가 자격 증명 생성 중에 제조업체, 모델 및 보안 특성에 대한 정보를 제공할 수 있도록 합니다. 이 정보는 Relying Party(RP)가 authenticator를 신뢰할지 여부를 결정하는 데 도움이 됩니다.
서로 다른 attestation 형식은 이 데이터가 어떻게 구조화되고 검증되는지를 정의합니다. 일반적으로 사용되는 세 가지 형식은 android-key, packed 및 fido-u2f, apple 또는 none과 같은 기타 형식입니다. 기본적으로 모든 attestation 형식이 활성화되어 있습니다. 지원되는 attestation 형식 목록은 아래에서 확인할 수 있습니다.
- NoneAttestation: 이 경우 attestation 데이터가 반환되지 않습니다. 디바이스 식별자 노출을 방지하여 사용자 개인정보를 우선시합니다. 디바이스 출처에 신경 쓰지 않는 애플리케이션에서 일반적입니다.
- PackedAttestation: 많은 authenticator가 사용하는 유연하고 간결한 형식입니다. authenticator는 attestation 인증서와 서명을 반환합니다. 다음일 수 있습니다: Full attestation: 공급업체가 제공한 키와 cert로 서명됨 또는 Self attestation: credential private key를 사용하여 서명됨. 다양한 플랫폼에서 가장 널리 사용됩니다(예: YubiKey, Windows Hello).
- TPMAttestation: Trusted Platform Module(TPM)이 있는 장치에서 사용됩니다. 증명은 TPM의 키를 사용하여 서명되며 인증서 체인을 포함합니다. TPM 칩이 있는 Enterprise 데스크톱/노트북(예: Windows 머신)에서 사용됩니다.
- AndroidKeyAttestation: Android Keystore를 사용하는 Android 디바이스에서 사용됩니다. 키는 하드웨어에서 생성되며, attestation은 디바이스 제조업체가 발급한 인증서 체인으로 서명된 정보를 포함합니다. 하드웨어 지원 keystore(TEE 또는 StrongBox)가 있는 Android 폰에서 사용됩니다.
- AppleAttestation: Touch ID 및 Face ID와 같은 Apple 플랫폼 인증자가 사용합니다. Attestation은 Apple의 내부 API에 의해 생성되며 특수 인증서 형식을 포함합니다. Apple 생체 인식을 사용하는 Safari에서 사용됩니다.
- FidoU2FAttestation: FIDO U2F 인증자가 사용하는 레거시 증명 형식. U2F 호환 인증서와 서명을 반환합니다. FIDO U2F를 지원하는 구형 보안 키(예: 초기 YubiKey)에서 사용됩니다.
WebAuthn API에서 AllowCredentials는 인증 프로세스(navigator.credentials.get()을 통한) 중에 사용되는 선택적 필드입니다. 이는 특정 Relying Party(RP)에 대해 사용자를 인증할 수 있도록 허용된 자격 증명 ID 목록을 지정합니다. 이 메커니즘을 통해 RP는 로그인 시도에 어떤 자격 증명이 유효한 것으로 간주되는지 제어할 수 있습니다. credentials 속성에는 다음 필드가 있습니다.
- AllowCredentials: 활성화되면(기본적으로 false) 사용자를 인증할 수 있는 자격 증명 ID 목록을 지정합니다
- ExcludeCredentials: 사용자 이름이 주어지면 서버 구성 요소에 이미 저장된 모든 기존 자격 증명을 표시합니다.
- Limit: ExcludeCredentials가 true일 때 전송될 최대 자격 증명 수입니다.
WebAuthn Protocol
- WebAuthn Registration: 서버가 챌린지를 생성하여 클라이언트에 보내면, 클라이언트는 인증자(예: 보안 키 또는 생체 인식 디바이스)를 사용하여 키 쌍을 생성합니다. 공개 키는 다시 전송되어 향후 인증을 위해 서버에 저장됩니다. 아래에서 등록 흐름 이벤트에 대한 자세한 정보를 찾을 수 있습니다:
- WebAuthn Authentication: 서버가 클라이언트에 챌린지를 보내면, 클라이언트는 인증자에 저장된 이전에 등록된 개인 키를 사용하여 서명합니다. 서명된 응답은 서버가 저장된 공개 키를 사용하여 검증하여 사용자의 신원을 확인합니다. 아래에서 인증 흐름 이벤트에 대한 자세한 정보를 찾을 수 있습니다:
- MDS: FIDO Alliance Metadata Service(MDS)는 relying party가 authenticator attestation을 검증하고 디바이스 모델의 진정성을 증명하는 데 사용하는 Metadata Statement의 중앙 집중식 저장소입니다.
- Authorization: 클라이언트는 인증 플로 중에 서버로부터 bearer 토큰을 요청할 수 있습니다. 이 토큰은 나중에 passkey를 사용하여 로그인할 필요 없이 새 WebSocket 또는 HTTP 연결을 여는 데 사용할 수 있습니다.