과거에는 로그인 상태, 사용자가 사용 중인 기기에 대한 정보 또는 사용자가 알려져 있고 신뢰할 수 있는지 여부 등 사용자 상태에 대한 정보를 저장하고 전달하는 데 서드 파티 쿠키가 사용되었습니다. 예를 들어 사용자가 SSO로 로그인했는지 여부, 사용자가 특정 유형의 호환 기기를 보유하고 있는지 또는 사용자가 알려져 있고 신뢰할 수 있는지 여부입니다. 서드 파티 쿠키 지원이 중단됨에 따라 이러한 사용 사례 중 상당수를 다른 수단으로 지원해야 합니다.
비공개 상태 토큰은 웹에서 정보를 공유하는 방법을 제공하지만, 실제로 공유할 수 있는 데이터의 양을 관리하면서 개인 정보를 보호하는 방식으로 이루어집니다.
비공개 상태 토큰 (이전의 트러스트 토큰)을 사용하면 사용자의 진위에 대한 신뢰를 한 컨텍스트에서 다른 컨텍스트로 전달하는 동시에 사이트에서 수동 추적 없이 사기를 방지하고 실제 사람과 봇을 구분할 수 있습니다.
이 문서에서는 비공개 상태 토큰 (PST)을 구현하기 위한 기술 세부정보를 간략히 설명합니다. 대략적인 개요는 PST 개요를 참조하세요.
비공개 상태 토큰은 어떻게 작동하나요?
PST에서 이해해야 할 주요 관계는 발급기관과 사용하는 사용자 간의 관계입니다. 발급기관과 사용하는 사용자는 동일한 회사 내에 있을 수 있습니다.
- 발급기관 - 이러한 개체는 사용자에 대한 신호 (예: 사용자가 봇인지 여부)를 가지고 이 신호를 사용자 기기에 저장된 토큰에 삽입합니다 (자세한 내용은 다음 섹션 참고).
- 사용자 - 이러한 항목은 사용자에 관한 신호가 없지만 사용자에 대해 알아야 할 정보 (예: 사용자가 봇인지 여부)가 있어야 하고 사용자의 신뢰성을 파악하기 위해 발급기관에서 받은 토큰 사용을 요청해야 합니다.
모든 PST 상호작용에서는 발급기관과 사용자가 웹 전반에서 신호를 공유하기 위해 협력해야 합니다. 이러한 신호는 개인을 식별하기에 충분히 상세하지 않은 대략적인 값입니다.
비공개 상태 토큰이 나에게 적합한가요?
신뢰 결정을 내리고 이러한 정보를 다양한 컨텍스트에서 사용할 수 있도록 하려는 기업은 PST를 활용할 수 있습니다. PST의 잠재적인 사용 사례에 대한 자세한 내용은 PST 사용 사례에 대한 문서를 참조하세요.
토큰 발행 및 사용
PST는 다음과 같은 세 단계로 구현됩니다.
- 토큰 발급
- 토큰 사용
- 사용 기록 전달
첫 번째 단계에서는 토큰이 브라우저에 발급됩니다 (일반적으로 일종의 유효성 검사 후). 두 번째 단계에서는 다른 주체가 해당 토큰의 값을 읽기 위해 발급된 토큰 사용을 요청합니다. 마지막 단계에서, 사용 당사자는 토큰에 포함된 값이 있는 사용 기록 (RR)을 받습니다. 그러면 소유권을 사용하는 당사자는 이 기록을 다양한 목적으로 이 사용자의 증명으로 사용할 수 있습니다.
토큰 전략 정의
토큰 전략을 정의하려면 PST 키 개념 (토큰 및 사용 레코드), 변수, 동작, 제한사항을 파악하여 사용 사례에 적용할 수 있는지 파악해야 합니다.
토큰과 사용 레코드: 서로 어떤 관계인가요?
각 기기는 최상위 웹사이트 및 발급기관당 최대 500개의 토큰을 저장할 수 있습니다. 또한 각 토큰에는 발급기관에서 이를 발급하는 데 사용한 키를 알려주는 메타데이터가 있습니다. 이 정보는 사용 프로세스 중에 토큰 사용 여부를 결정하는 데 사용될 수 있습니다. PST 데이터는 사용자 기기의 브라우저에 의해 내부적으로 저장되며 PST API로만 액세스할 수 있습니다.
토큰이 사용되면 기기 사용 기록 (RR)이 기기에 저장됩니다. 이 스토리지는 향후 사용 시 캐시 역할을 합니다. 기기, 페이지, 발급기관별로 48시간마다 2개의 토큰을 사용할 수 있습니다. 새로운 사용 호출은 가능한 경우 발급자에게 요청을 야기하는 대신 캐시된 RR을 사용합니다.
- 새 토큰이 발급됩니다 (발급기관, 사이트, 기기당 최대 500개).
- 모든 토큰은 기기 내 토큰 저장소에 저장됩니다 (쿠키 저장소와 유사).
- 활성 RR이 없으면 발급 후 새 RR이 생성될 수 있습니다(48시간마다 최대 2개).
- RR은 만료될 때까지 활성 상태로 간주되며 로컬 캐시로 사용됩니다.
- 새로운 사용 호출이 로컬 캐시에 도달합니다 (새 RR이 생성되지 않음).
사용 사례를 정의한 후에는 RR의 수명을 신중하게 정의해야 합니다. 이는 자신의 사례에서 RR을 사용할 수 있는 횟수를 정의하기 때문입니다.
전략을 정의하기 전에 다음과 같은 중요한 행동과 변수를 이해해야 합니다.
| 변수 / 행동 | 설명 | 잠재적 사용량 |
|---|---|---|
| 토큰 키 메타데이터 | 각 토큰은 하나의 암호화 키만 사용하여 발급될 수 있으며 PST에서는 발급기관당 6개의 키로 제한됩니다. | 이 변수를 사용하는 한 가지 가능한 방법은 암호화 키를 기반으로 토큰에 대한 신뢰 범위를 정의하는 것입니다 (예: 키 1 = 높은 신뢰도, 키 6 = 신뢰 없음). |
| 토큰 만료일 | 토큰 만료일은 키 만료일과 동일합니다. | 키는 최소 60일마다 순환될 수 있으며 잘못된 키로 발급된 모든 토큰도 잘못된 것으로 간주됩니다. |
| 토큰 사용 비율 제한 | 토큰 사용은 기기 및 발급기관당 48시간마다 2회로 제한됩니다. | 48시간마다 사용 사례에 필요한 예상 사용 횟수에 따라 다릅니다. |
| 최상위 출처당 최대 발급기관 수 | 최상위 출처당 최대 발급기관 수는 현재 2개입니다. | 각 페이지의 발급기관을 신중하게 정의합니다. |
| 기기의 발급기관당 토큰 | 특정 기기에서 발급기관당 최대 토큰 수는 현재 500개입니다. | 토큰 수는 발급기관당 500개 미만으로 유지해야 합니다. 토큰을 발행하려고 할 때 웹페이지에서 오류를 처리해야 합니다. |
| 키 약정 순환 | 모든 PST 발급기관은 60일마다 변경할 수 있는 키 약정과 이보다 빠른 순환은 무시되는 값으로 엔드포인트를 노출해야 합니다. | 키가 60일 이내에 만료되는 경우 서비스 중단을 방지하려면 해당 날짜 이전에 키 약정을 업데이트해야 합니다(세부정보 참조). |
| 사용 기록 기간 | RR의 수명은 만료일을 결정하기 위해 정의할 수 있습니다. RR은 발급기관에 보내는 불필요한 새로운 사용 호출을 방지하기 위해 캐시되므로 최신 사용 신호를 확보하는 것이 중요합니다. | 48시간마다 토큰 2개의 사용 비율 제한이 있으므로 RR의 수명을 정의하여 최소한 이 기간 동안 성공적으로 사용 호출을 실행할 수 있도록 하는 것이 중요합니다 (RR 수명은 적절하게 설정해야 함). 이 수명은 몇 주 단위로 설정하는 것이 좋습니다. |
시나리오 예시
시나리오 #1: RR 수명 24시간 미만 (t=t)이고 48시간 동안 사용이 여러 번 수행됨
시나리오 #2: RR 수명은 24시간이고 48시간 동안 사용이 여러 번 실행됩니다.
시나리오 #3: RR 수명은 48시간이고 48시간 동안 사용이 여러 번 실행됩니다.
데모 실행
PST를 채택하기 전에 먼저 데모를 설정하는 것이 좋습니다. PST 데모를 사용해 보려면 데모 발급기관 키 약정을 사용 설정하는 플래그를 사용하여 Chrome을 실행해야 합니다 (데모 페이지의 안내 참고).
이 데모를 실행하면 브라우저가 데모 발급기관 및 신청자 서버를 사용하여 토큰을 제공하고 소비합니다.
기술적 고려사항
데모는 다음 단계를 구현할 때 가장 잘 실행됩니다.
- 플래그를 사용하여 Chrome을 실행하기 전에 모든 Chrome 인스턴스를 중지해야 합니다.
- Windows 컴퓨터에서 실행 중인 경우 Chrome 실행 바이너리에 매개변수를 전달하는 방법에 관한 이 가이드를 참고하세요.
- 데모 애플리케이션을 사용하는 동안 애플리케이션 > 저장소 > 비공개 상태 토큰에서 Chrome DevTools를 열어 데모 발급기관에서 발급/사용한 토큰을 확인합니다.
채택 설정
발급기관 되기
발급기관은 PST에서 중요한 역할을 합니다. 토큰에 값을 할당하여 사용자가 봇인지 확인합니다. 발급기관으로서 PST를 시작하려면 발급기관 등록 프로세스를 완료하여 등록해야 합니다.
발급기관이 되려면 발급기관 웹사이트의 운영자가 'New PST Issuer' 템플릿을 사용하여 GitHub 저장소에서 새 문제를 열어야 합니다. 저장소의 안내에 따라 문제를 작성합니다. 엔드포인트가 확인되면 이 저장소에 병합되고 Chrome 서버 측 인프라에서 해당 키를 가져오기 시작합니다.
발급기관 서버
발급기관과 리버스는 PST의 핵심 행위자이고, 서버와 토큰은 PST의 핵심 도구입니다. 토큰과 GitHub 문서에 관한 몇 가지 세부정보는 이미 제공했지만, PST 서버에 대한 세부정보를 제공하고자 합니다. PST 발급기관으로 설정하려면 먼저 발급 서버를 설정해야 합니다.
환경 배포: 발급기관 서버
토큰 발급기관 서버를 구현하려면 HTTP 엔드포인트를 노출하는 자체 서버 측 애플리케이션을 빌드해야 합니다.
발급기관 구성요소는 (1) 발급기관 서버와 (2) 토큰 발급기관이라는 두 가지 기본 모듈로 구성됩니다.
모든 웹 대상 애플리케이션과 마찬가지로 발급기관 서버에 추가적인 보호 레이어를 적용하는 것이 좋습니다.
발급기관 서버: 이 구현 예시에서 발급 서버는 Express 프레임워크를 사용하여 발급기관 HTTP 엔드포인트를 호스팅하는 Node.js 서버입니다. GitHub의 샘플 코드를 확인할 수 있습니다.
토큰 발급기관: 발급기관 암호화 구성요소에는 특정 언어가 필요하지 않지만 이 구성요소의 성능 요구사항으로 인해 Boring SSL 라이브러리를 사용하여 토큰을 관리하는 C 구현을 예로 제공합니다. 발급기관 코드 예시 및 GitHub에서 설치에 관한 자세한 내용을 확인할 수 있습니다.
키: 토큰 발급기관 구성요소는 커스텀 EC 키를 사용하여 토큰을 암호화합니다. 이러한 키는 보호되고 보안 저장소에 저장되어야 합니다.
발급기관 서버의 기술 요구사항
프로토콜에 따라 발급기관 서버에 HTTP 엔드포인트를 두 개 이상 구현해야 합니다.
- 키 커밋 (예:
/.well-known/private-state-token/key-commitment): 암호화 공개 키 세부정보가 유효한 서버인지 확인하기 위해 브라우저에서 공개 키 세부정보를 제공하는 엔드포인트입니다. - 토큰 발급 (예:
/.well-known/private-state-token/issuance): 모든 토큰 요청이 처리되는 토큰 발급 엔드포인트입니다. 이 엔드포인트가 토큰 발급기관 구성요소의 통합 지점이 됩니다.
앞서 언급했듯이 이 서버가 처리할 것으로 예상되는 높은 트래픽 때문에 변화하는 수요에 따라 백엔드를 조정할 수 있도록 확장 가능한 인프라 (예: 클라우드 환경)를 사용하여 배포하는 것이 좋습니다.
발급기관 서버에 호출 전송
새 토큰을 발급하기 위해 발급기관 스택에 웹사이트 가져오기 호출을 구현합니다.
// issuer request
await fetch("/.well-known/private-state-token/issuance", {
method: "POST",
privateToken: {
version: 1,
operation: "token-request"
}
});
쿠폰 사용 서버
서버 측 애플리케이션을 직접 빌드하여 토큰 사용 서비스를 구현해야 합니다. 이렇게 하면 발급기관이 보낸 토큰을 읽을 수 있습니다. 다음 단계에서는 토큰 사용 방법과 해당 토큰과 연결된 사용 레코드를 읽는 방법을 간략히 설명합니다.
발급기관과 사용하는 주체를 동일한 서버 (또는 서버 그룹)에서 실행하도록 선택할 수 있습니다.
쿠폰 사용 서버 기술 요구사항
프로토콜에 따라 사용자 서버에 HTTP 엔드포인트를 두 개 이상 구현해야 합니다.
/.well-known/private-state-token/redemption: 모든 토큰 사용이 처리되는 엔드포인트입니다. 이 엔드포인트에서 토큰 사용자 구성요소가 통합됩니다.
등록자 서버에 호출 보내기
토큰을 사용하려면 이전에 발급된 토큰을 사용하려면 웹사이트 사용자 스택에 대한 가져오기 호출을 구현해야 합니다.
// redemption request
await fetch("/.well-known/private-state-token/redemption", {
method: "POST",
privateToken: {
version: 1,
operation: "token-redemption",
refreshPolicy: "none"
}
});
코드 샘플을 참고하세요.
토큰을 사용한 후 다른 가져오기 호출을 수행하여 사용 레코드 (RR)를 보낼 수 있습니다.
// attach redemption records from the issuers to the request
await fetch("<DESTINATION_RESOURCE>", {
method: "POST",
privateToken: {
version: 1,
operation: "send-redemption-record",
issuers: [<ISSUER_DOMAIN>]
}
});
코드 샘플을 참고하세요.
구현 배포
구현을 테스트하려면 먼저 호출을 실행하는 웹페이지로 이동하여 로직에 따라 토큰이 생성되었는지 확인합니다. 백엔드에서 호출이 사양에 따라 수행되었는지 확인합니다. 그런 다음 사용 통화가 이루어진 웹페이지로 이동하여 로직에 따라 RR이 생성되었는지 확인합니다.
실제 배포
특정 사용 사례에 속하는 타겟 웹사이트를 선택하는 것이 좋습니다.
- 소량의 월간 방문 수 (월 100만 회 미만): 먼저 소규모 잠재고객에게 API를 배포해야 합니다.
- 사용자가 직접 관리하고 제어: 필요한 경우 복잡한 승인 없이도 빠르게 구현을 사용 중지할 수 있습니다.
- 발급기관을 두 개 이하로 제한: 테스트 간소화를 위해 토큰 수를 제한합니다.
- 2명 이하의 쿠폰 사용: 문제가 발생한 경우 문제 해결을 간소화해야 합니다.
문제 해결
Chrome DevTools의 '네트워크' 및 '애플리케이션' 탭에서 PST를 검사할 수 있습니다.
네트워크 탭에서 다음 단계를 따릅니다.
애플리케이션 탭에서 다음을 수행합니다.
이 DevTools 통합에 대해 자세히 알아보세요.
서버 권장사항 및 문제 해결
발급기관과 사용자 서버가 효과적으로 작동하려면 PST에 대한 액세스, 보안, 로깅 또는 트래픽 문제가 발생하지 않도록 다음 권장사항을 구현하는 것이 좋습니다.
- 엔드포인트는 TLS 1.3 또는 1.2를 사용하여 강력한 암호화를 적용해야 합니다.
- 인프라가 가변 트래픽 볼륨(급증 포함)을 처리할 준비가 되어 있어야 합니다.
- 키가 액세스 제어 정책, 키 관리 전략, 업무 연속성 계획에 따라 안전하게 보호되고 있는지 확인하세요.
- 스택에 관측 가능성 측정항목을 추가하여 프로덕션 단계로 전환한 후 사용량, 병목 현상, 성능 문제를 파악할 수 있습니다.
추가 정보
- 개발자 문서 검토:
- PST와 관련 기능을 빠르게 파악하려면 먼저 개요를 읽어보세요.
- PST 소개 동영상 시청하기
- PST 데모를 사용해 보세요.
- 또한 API 설명서를 참고하여 자세한 내용을 알아보세요.
- API의 현재 사양에 관해 자세히 알아보세요.
- GitHub 문제 또는 W3C 호출을 통해 대화에 기여합니다.
- 용어에 대한 자세한 내용은 개인 정보 보호 샌드박스 용어집을 검토하세요.
- '오리진 트라이얼' 또는 'Chrome 플래그'와 같은 Chrome 개념에 대해 자세히 알아보려면 goo.gle/cc에서 제공되는 짧은 동영상과 도움말을 살펴보세요.