기기 결합 세션 사용자 인증 정보 (DBSC)는 하드웨어 지원 세션 보안을 추가하여 인증을 강화합니다.
소개
많은 웹사이트에서 사용자 인증에 장기 쿠키를 사용하지만 이러한 쿠키는 세션 도용에 취약합니다. 기기 전용 세션 사용자 인증 정보 (DBSC)는 이러한 위험을 완화하기 위해 하드웨어 지원 보안 레이어를 추가하여 세션이 특정 기기에 바인딩되도록 합니다.
이 가이드는 웹 애플리케이션에서 인증 흐름을 유지하는 개발자를 대상으로 합니다. DBSC의 작동 방식과 사이트에 통합하는 방법을 설명합니다.
DBSC 작동 방식
대략적으로 DBSC는 사용자의 기기와 연결된 암호화 키 쌍을 도입합니다. Chrome은 로그인 중에 이 키 쌍을 생성하고 가능한 경우 신뢰할 수 있는 플랫폼 모듈 (TPM)과 같은 보안 하드웨어에 비공개 키를 저장합니다. 세션은 단기 쿠키를 사용합니다. 이러한 쿠키 중 하나가 만료되면 Chrome은 쿠키를 새로고침하기 전에 비공개 키를 보유하고 있음을 증명합니다. 이 프로세스는 세션 연속성을 원래 기기에 연결합니다.
사용자의 기기에서 안전한 키 저장소를 지원하지 않는 경우 DBSC는 인증 흐름을 중단하지 않고 원활하게 표준 동작으로 대체됩니다.
구현 개요
DBSC를 애플리케이션에 통합하려면 다음을 변경해야 합니다.
Sec-Session-Registration
헤더를 포함하도록 로그인 흐름을 수정합니다.- 다음을 실행하는 세션 등록 엔드포인트를 추가합니다.
- 공개 키를 사용자의 세션에 연결합니다.
- 세션 구성을 제공합니다.
- 짧은 시간 동안 유지되는 쿠키로 전환합니다.
- 쿠키 갱신 및 키 소유권 유효성 검사를 처리하는 새로고침 엔드포인트를 추가합니다.
대부분의 기존 엔드포인트는 변경할 필요가 없습니다. DBSC는 추가적이고 중단되지 않도록 설계되었습니다.
필요한 짧은 시간의 쿠키가 누락되거나 만료되면 Chrome은 요청을 일시중지하고 쿠키를 새로고침하려고 시도합니다. 이렇게 하면 앱에서 평소의 세션 쿠키 확인을 계속 사용하여 사용자가 로그인되어 있는지 확인할 수 있습니다. 이는 일반적인 인증 흐름과 일치하므로 DBSC는 로그인 로직을 최소한만 변경해도 작동합니다.
구현 단계
이 섹션에서는 로그인 흐름을 수정하고, 세션 등록을 처리하고, 짧은 시간의 쿠키 새로고침을 관리하는 방법을 비롯하여 인증 시스템에 필요한 변경사항을 설명합니다. 각 단계는 기존 인프라와 원활하게 통합되도록 설계되었습니다.
구현 단계는 DBSC가 활성화되어 있을 때 로그인한 사용자가 경험하는 일반적인 흐름(로그인 시 등록 후 정기적으로 짧은 시간 동안 쿠키 새로고침)을 따릅니다. 앱의 세션 민감도 수준에 따라 각 단계를 개별적으로 테스트하고 구현할 수 있습니다.
1. 로그인 흐름 수정
사용자가 로그인한 후에는 장기 쿠키와 Sec-Session-Registration
헤더로 응답합니다. 예를 들면 다음과 같습니다.
세션 등록에 성공하면 다음 HTTP 응답 헤더가 반환됩니다.
HTTP/1.1 200 OK
Sec-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax
기기가 보안 키 저장소를 지원하는 경우 Chrome은 JSON 웹 토큰 (JWT)의 공개 키를 사용하여 /StartSession
엔드포인트에 연결합니다.
이 예에서 auth_cookie
는 세션 토큰을 나타냅니다. 세션 구성의 name
필드와 일치하고 애플리케이션 전체에서 일관되게 사용되는 한 이 쿠키의 이름을 원하는 대로 지정할 수 있습니다.
2. 세션 등록 엔드포인트 구현
/StartSession
에서 서버는 다음을 실행해야 합니다.
- 수신된 공개 키를 사용자의 세션과 연결합니다.
- 세션 구성으로 응답합니다.
- 장기 쿠키를 단기 쿠키로 대체합니다.
다음 예에서는 10분 후에 만료되도록 짧은 시간의 쿠키가 구성되어 있습니다.
HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutesSet-Cookie: Domain=example.com; Secure; SameSite=Lax
{
"session_identifier": "session_id",
"refresh_url": "/RefreshEndpoint",
"scope": {
"origin": "https://example.com",
"include_site": true,
"scope_specification": [
{ "type": "exclude", "domain": "*.example.com", "path": "/static" }
]
},
"credentials": [{
"type": "cookie",
"name": "auth_cookie",
"attributes": "Domain=example.com; Secure; SameSite=Lax"
}]
}
3. 새로고침 엔드포인트 구현
짧은 시간의 쿠키가 만료되면 Chrome에서 비공개 키 소유를 증명하기 위한 새로고침 흐름을 시작합니다. 이 프로세스에는 Chrome과 서버의 조정된 작업이 포함됩니다.
Chrome은 사용자의 요청을 애플리케이션으로 연기하고
/RefreshEndpoint
에 새로고침 요청을 전송합니다.POST /RefreshEndpoint HTTP/1.1 Sec-Session-Id: session_id
서버가 챌린지로 응답합니다.
HTTP/1.1 401 Unauthorized Sec-Session-Challenge: "challenge_value"
Chrome은 저장된 비공개 키를 사용하여 챌린지에 서명하고 요청을 다시 시도합니다.
POST /RefreshEndpoint HTTP/1.1 Sec-Session-Id: session_id Sec-Session-Response: <JWT proof>
서버가 서명된 증거를 확인하고 새로고침된 짧은 시간의 쿠키를 발급합니다.
HTTP/1.1 200 OK Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax
Chrome은 새로고침된 쿠키를 수신하고 원래 지연된 요청을 재개합니다.
대체 통합 패턴
복원력을 개선하기 위해 사이트는 짧은 시간 지속되는 쿠키와 함께 DBSC가 아닌 두 번째 쿠키를 추가할 수 있습니다. 이 장기 쿠키는 새롭고 짧은 기간의 토큰을 발급하는 데만 사용되며 실제로 인증되지 않은 요청과 일시적인 DBSC 실패를 구분하는 데 도움이 됩니다.
- 장기 쿠키는 DBSC가 실패하더라도 유지됩니다.
- 수명이 짧은 쿠키는 DBSC를 사용하여 새로고침되며 민감한 작업에 필요합니다.
이 패턴을 사용하면 사이트에서 특수한 케이스를 처리하는 방법을 더 효과적으로 제어할 수 있습니다.
주의사항 및 대체 동작
다음 시나리오에서는 Chrome이 DBSC 작업을 건너뛰고 DBSC에서 관리하는 짧은 시간의 쿠키 없이 요청을 전송할 수 있습니다.
- 네트워크 오류 또는 서버 문제로 인해 새로고침 엔드포인트에 연결할 수 없습니다.
- TPM이 사용 중이거나 서명 오류가 발생했습니다. TPM은 시스템 프로세스 간에 공유되므로 과도한 새로고침으로 인해 비율 제한이 초과될 수 있습니다.
- DBSC에서 관리하는 짧은 시간의 쿠키는 서드 파티 쿠키이며 사용자가 브라우저 설정에서 서드 파티 쿠키를 차단했습니다.
이 경우 Chrome은 장기 쿠키가 여전히 있는 경우 장기 쿠키를 사용합니다. 이 대체는 구현에 장기 및 단기 쿠키가 모두 포함된 경우에만 작동합니다. 그렇지 않으면 Chrome은 쿠키 없이 요청을 전송합니다.
요약
기기 결합 세션 사용자 인증 정보는 애플리케이션을 최소한만 변경하여 세션 보안을 개선합니다. 세션을 특정 기기에 연결하여 세션 도용에 대한 보호를 강화합니다. 대부분의 사용자는 서비스 중단 없이 이 기능의 이점을 누리며 DBSC는 지원되지 않는 하드웨어로 원활하게 대체됩니다.
자세한 내용은 DBSC 사양을 참고하세요.