기기 바운드 세션 사용자 인증 정보 (DBSC)는 하드웨어 지원 세션 보안을 추가하여 인증을 강화합니다.
소개
많은 웹사이트에서 사용자 인증을 위해 수명이 긴 쿠키를 사용하지만 이러한 쿠키는 세션 하이재킹에 취약합니다. 기기 바운드 세션 사용자 인증 정보 (DBSC)는 이러한 위험을 완화하기 위해 하드웨어 지원 보안 레이어를 추가하여 세션이 특정 기기에 바인딩되도록 합니다.
이 가이드는 웹 애플리케이션에서 인증 흐름을 유지하는 개발자를 대상으로 합니다. DBSC의 작동 방식과 사이트에 통합하는 방법을 설명합니다.
DBSC 작동 방식
개략적으로 DBSC는 사용자의 기기와 연결된 암호화 키 쌍을 도입합니다. Chrome은 로그인 중에 이 키 쌍을 생성하고, 사용 가능한 경우 신뢰할 수 있는 플랫폼 모듈 (TPM)과 같은 보안 하드웨어에 비공개 키를 저장합니다. 세션은 단기 쿠키를 사용합니다. 이러한 쿠키 중 하나가 만료되면 Chrome은 쿠키를 새로고침하기 전에 비공개 키의 소유권을 증명합니다. 이 프로세스는 세션 연속성을 원래 기기에 연결합니다.
사용자의 기기가 보안 키 저장소를 지원하지 않는 경우 DBSC는 인증 흐름을 중단하지 않고 정상적으로 표준 동작으로 대체됩니다.
구현 개요
애플리케이션에 DBSC를 통합하려면 다음 변경사항을 적용해야 합니다.
Secure-Session-Registration헤더를 포함하도록 로그인 흐름을 수정합니다.- 다음을 충족하는 세션 등록 엔드포인트를 추가합니다.
- 공개 키를 사용자의 세션과 연결합니다.
- 세션 구성을 제공합니다.
- 단기 쿠키로 전환됩니다.
- 쿠키 갱신 및 키 소유권 확인을 처리하는 새로고침 엔드포인트 추가
기존 엔드포인트 대부분은 변경할 필요가 없습니다. DBSC는 추가적이고 방해가 되지 않도록 설계되었습니다.
필수 단기 쿠키가 누락되거나 만료되면 Chrome은 요청을 일시중지하고 쿠키를 새로고침하려고 시도합니다. 이렇게 하면 앱에서 일반적인 세션 쿠키 확인을 계속 사용하여 사용자가 로그인되어 있는지 확인할 수 있습니다. 이는 일반적인 인증 흐름과 일치하므로 로그인 로직을 최소한으로 변경하여 DBSC를 사용할 수 있습니다.
구현 단계
이 섹션에서는 로그인 흐름을 수정하고, 세션 등록을 처리하고, 수명이 짧은 쿠키 새로고침을 관리하는 방법 등 인증 시스템에 필요한 변경사항을 설명합니다. 각 단계는 기존 인프라와 원활하게 통합되도록 설계되었습니다.
구현 단계는 로그인 시 등록 후 정기적인 단기 쿠키 새로고침이 이어지는 로그인한 사용자가 DBSC가 활성 상태일 때 경험하는 일반적인 흐름을 따릅니다. 앱의 세션 민감도 수준에 따라 각 단계를 독립적으로 테스트하고 구현할 수 있습니다.

1. 로그인 흐름 수정
사용자가 로그인한 후에는 수명이 긴 쿠키와 Secure-Session-Registration 헤더로 응답합니다. 예를 들면 다음과 같습니다.
세션 등록이 완료되면 다음 HTTP 응답 헤더가 반환됩니다.
HTTP/1.1 200 OK
Secure-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-Secure-Session-Id: session_id서버가 챌린지로 응답합니다.
HTTP/1.1 403 Forbidden Secure-Session-Challenge: "challenge_value"Chrome은 저장된 비공개 키를 사용하여 챌린지에 서명하고 요청을 다시 시도합니다.
POST /RefreshEndpoint HTTP/1.1 Sec-Secure-Session-Id: session_id Secure-Session-Response: <JWT proof>서버가 서명된 증명을 검증하고 갱신된 단기 쿠키를 발급합니다.
HTTP/1.1 200 OK Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=LaxChrome이 새로고침된 쿠키를 수신하고 원래 지연된 요청을 재개합니다.
대체 통합 패턴
복원력을 개선하기 위해 사이트에서는 수명이 짧은 쿠키와 함께 두 번째 비DBSC 쿠키를 추가할 수 있습니다. 이 장기 쿠키는 새로운 단기 토큰을 발급하는 데만 사용되며, 인증되지 않은 요청과 임시 DBSC 실패를 구분하는 데 도움이 됩니다.
- 장기 쿠키는 DBSC가 실패하더라도 유지됩니다.
- 수명이 짧은 쿠키는 DBSC를 사용하여 새로고침되며 민감한 작업에 필요합니다.
이 패턴을 사용하면 사이트에서 특수한 사례를 처리하는 방법을 더 효과적으로 제어할 수 있습니다.
주의사항 및 대체 동작
Chrome은 다음 시나리오에서 DBSC 작업을 건너뛰고 DBSC 관리 단기 쿠키 없이 요청을 보낼 수 있습니다.
- 네트워크 오류 또는 서버 문제로 인해 새로고침 엔드포인트에 연결할 수 없습니다.
- TPM이 사용 중이거나 서명 오류가 발생합니다. TPM은 시스템 프로세스 전반에서 공유되므로 과도한 새로고침은 속도 제한을 초과할 수 있습니다.
- DBSC에서 관리하는 수명이 짧은 쿠키는 서드 파티 쿠키이며 사용자가 브라우저 설정에서 서드 파티 쿠키를 차단했습니다.
이러한 상황에서 Chrome은 장기 쿠키가 아직 있는 경우 장기 쿠키를 사용하는 것으로 대체됩니다. 이 대체는 구현에 수명이 긴 쿠키와 수명이 짧은 쿠키가 모두 포함된 경우에만 작동합니다. 그렇지 않으면 Chrome은 쿠키 없이 요청을 보냅니다.
요약
기기 바운드 세션 사용자 인증 정보는 애플리케이션을 최소한으로 변경하여 세션 보안을 개선합니다. 세션을 특정 기기에 연결하여 세션 하이재킹에 대한 보호를 강화합니다. 대부분의 사용자는 중단 없이 이점을 누릴 수 있으며 DBSC는 지원되지 않는 하드웨어에서 정상적으로 대체됩니다.
자세한 내용은 DBSC 사양을 참고하세요.