이 페이지는 Cloud Translation API를 통해 번역되었습니다.

비공개 상태 토큰 개발자 가이드

과거에는 정보를 저장하고 전달하는 데 서드 파티 쿠키가 사용되었습니다. 사용자 상태 정보(예: 로그인 상태, 기기에 대한 정보) 또는 그들이 알려지고 신뢰할 수 있는지 여부 예를 들어 사용자가 SSO로 로그인한 상태인지 여부(사용자가 특정 유형의 호환되는 또는 사용자가 알려져 있고 신뢰할 수 있는지에 따라 달라집니다. 다음으로 바꿉니다. 서드 파티 쿠키 지원 중단 이러한 사용 사례 중 다수는 다른 수단으로 지원해야 합니다.

비공개 상태 토큰은 웹 전반에서 정보를 공유하는 방법을 제공하지만 실제로 개인 정보를 보호할 수 있는 데이터의 양을 통제함으로써 공유할 수 있습니다.

비공개 상태 토큰 (이전의 신뢰 토큰)은 한 문맥에서 다른 문맥으로 전달될 수 있는 진정성 확보를 통해 수동 추적 없이 사기를 방지하고 실제 사람과 봇을 구별합니다.

이 문서에서는 비공개 상태 구현을 위한 기술 세부정보를 간략히 설명합니다. 토큰 (PST) 자세한 내용은 PST 개요

PST 학습 흐름 — PST의 학습 과정: 이 프로세스는 API에 대한 이해부터 자체 토큰 전략 (더 많은 제품 또는 비즈니스 관련 활동)을 정의하는 것으로 시작하여 여러 단계로 구성됩니다. 이어서 기술 단계에서는 로컬 환경에서 데모를 구현한 다음 실제 사용 사례에 적용합니다.

비공개 상태 토큰은 어떻게 작동하나요?

PST에서 이해해야 할 주요 관계는 발급자와 사용자 간의 관계입니다. 발급기관과 사용자는 동일한 회사 내에 있을 수 있습니다.

발급기관 - 이러한 항목에는 사용자에 대한 신호가 있습니다. 예를 들어 해당 사용자가 봇인지 아닌지)에 대한 정보를 수집하고 이 신호를 사용자 기기에 저장된 토큰입니다 (자세한 내용은 다음 섹션 참조).
사용자 - 이러한 개체는 사용자에 대한 신호를 가지고 있지 않을 수 있지만 사용자에 관해 알아야 할 사항 (예: 해당 사용자가 봇인지 여부) 여부를 확인하고, 발급기관에서 받은 토큰을 사용하여 얼마나 신뢰할 수 있는지 평가한 점수입니다

모든 PST 상호작용에서는 발급자와 등록자가 협력하여 유용한 정보를 얻을 수 있습니다 이러한 신호는 상세하지 않은 대략적인 값입니다. 식별할 수 있습니다.

비공개 상태 토큰이 내게 적합한가요?

신뢰에 관한 결정을 내리고 이러한 정보가 신뢰받는 데 도움이 되기를 원하는 기업 PST가 도움이 될 수 있습니다. 잠재적 사용 사례에 관한 추가 정보 PST, PST 사용 사례에 관한 문서를 참고하세요

토큰 발행 및 사용

PST는 다음 세 단계로 구현됩니다.

토큰 발급
토큰 사용
사용 레코드 전달

첫 번째 단계에서는 브라우저에 토큰이 발급됩니다 (일반적으로 어떤 종류의 있습니다. 두 번째 단계에서는 다른 주체가 해당 토큰의 값을 읽기 위해 발급된 토큰입니다. 결승전 단계에서, 사용 당사자는 확인할 수 있습니다 그런 다음 사용 당사자는 해당 레코드를 증명할 수 있습니다.

비공개 상태 토큰의 기본 흐름 — 순서 다이어그램: 이 다이어그램은 두 웹사이트에서 특정 Chrome 인스턴스에 대한 신호를 교환하려는 실제 시나리오에서 PST의 기본적인 사용을 보여줍니다. 두 웹사이트는 서로 다른 순간에 발급 및 상환 작업을 수행하며, 둘 사이에 신뢰할 수 있는 신호를 교환할 수 있습니다.

토큰 전략 정의

토큰 전략을 정의하려면 PST 주요 개념 (토큰, 사용 기록), 변수, 행동 및 제한사항을 통해 잠재적인 사용 사례에 대해 생각해 보세요

토큰과 사용 레코드: 서로 어떤 관계가 있나요?

각 기기는 최상위 웹사이트 및 발급기관당 최대 500개의 토큰을 저장할 수 있습니다. 또한 각 토큰에는 발급기관이 이를 발급하는 데 사용한 키를 알려주는 메타데이터가 있습니다. 그 것이 토큰 사용 중에 토큰의 사용 여부를 결정하는 데 정보가 사용될 수 있습니다. 프로세스입니다 PST 데이터는 사용자 기기의 브라우저에 의해 내부적으로 저장되고 PST API에서만 액세스할 수 있습니다.

토큰이 사용되면 사용 레코드 (RR)가 기기에 저장됩니다. 이 저장용량은 향후 사용을 위한 캐시 역할을 합니다. 최대 2개까지 설정할 수 있습니다. 48시간마다 토큰을 사용할 수 있습니다. 새 혜택 사용 가능한 경우 발급자

새 토큰이 발급됩니다 (발급기관, 사이트, 기기당 최대 500개).
모든 토큰은 기기 내 토큰 저장소에 저장됩니다 (쿠키 저장소와 유사).
활성 RR을 찾을 수 없는 경우 발급 후 새 RR을 생성할 수 있습니다. (48시간마다 최대 2회)
RR은 만료 시까지 활성 상태로 간주되며 현지 통화로 사용됩니다. 있습니다.
새로운 사용 호출이 로컬 캐시에 도달합니다 (새 RR은 생성되지 않음).

사용 사례를 정의한 후에는 RR의 수명을 이렇게 하면 캠페인에서 해당 리소스를 사용할 수 있는 횟수가 있습니다.

사전에 다음과 같은 중요한 행동과 변수를 이해해야 합니다. 전략 정의:

변수 / 동작	설명	잠재적 사용량
토큰 키 메타데이터	각 토큰은 하나의 암호화 키만 사용하여 발급될 수 있으며 PST의 경우 발급기관당 키가 6개로 제한됩니다.	이 변수를 사용할 수 있는 한 가지 가능한 방법은 신뢰 범위를 정의하는 것입니다. 에 기반한 토큰 (예: 키 1 = 높은 신뢰 수준인 반면 키 6은 신뢰하지 않음).
토큰 만료일	토큰 만료일은 키 만료일과 동일합니다.	키는 최소 60일마다 순환될 수 있으며 잘못된 키도 잘못된 것으로 간주됩니다.
토큰 사용 비율 한도	기기 및 발급기관당 토큰 사용은 1회당 2회로 제한됩니다. 48시간이 걸립니다.	사용에 필요한 예상 사용 횟수에 따라 다릅니다. 48시간마다 케이스로 보냅니다.
최상위 출처당 최대 발급기관 수	현재 최상위 출처당 최대 발급기관 수는 2개입니다.	각 페이지의 발급기관을 신중하게 정의합니다.
기기의 발급기관별 토큰	현재 특정 기기의 발급기관당 최대 토큰 수는 개입니다. 500입니다.	토큰 수를 발급기관당 500개 미만으로 유지해야 합니다. 문제를 시도할 때 웹페이지의 오류를 처리해야 합니다. 토큰입니다.
주요 약정 순환	모든 PST 발급기관은 키로 엔드포인트를 노출해야 합니다. 60일마다 변경할 수 있고 더 빠르게 순환할 수 있는 약정입니다. 그 값은 무시됩니다.	키가 60일 이내에 만료되는 경우 서비스가 중단되지 않도록 이 날짜 전에 주요 약정을 업데이트해야 합니다 세부정보를 참조하세요.
사용 기록 수명	RR의 수명을 정의하여 만료일을 결정할 수 있음 있습니다. 불필요한 새로운 사용 호출을 방지하기 위해 RR이 캐시되기 때문에 게시자에게 최신 정보를 제공하는 것이 중요합니다 사용 신호	48시간마다 토큰 2개의 사용 비율 제한이 있으므로 RR의 수명을 정의해야 최소 이 기간 (RR)에 성공한 신청 통화 그에 따라 수명을 설정해야 합니다.) 이 매개변수를 수명을 주 단위로 지정할 수 있습니다

시나리오 예시

시나리오 #1: RR 기간이 24시간 미만 (t=t)이고 카드 사용이 다음과 같은 경우 48시간 동안 여러 번 수행되었습니다

PST 시나리오 1 예: 수명이 짧음 — 이 시나리오에서는 28시간 동안 사용자가 새 토큰을 사용하면 모든 RR이 만료됩니다.

시나리오 #2: RR 유효기간이 24시간이고 사용을 수행함 48시간 동안 여러 번

PST 시나리오 2 예: 24시간 수명 — RR의 수명이 24시간인 이 시나리오에서는 48시간 내내 아무런 제한 없이 혜택을 사용할 수 있습니다.

시나리오 #3: RR 유효기간이 48시간이고 사용을 수행한 경우 48시간 동안 여러 번

PST 시나리오 3 예: 수명 48시간 — RR의 수명이 48시간인 이 시나리오에서는 48시간 내내 아무런 제한 없이 혜택을 사용할 수 있습니다.

데모 실행

PST를 채택하기 전에 먼저 데모를 설정하는 것이 좋습니다. 사용해 보기 PST 데모를 실행하는 경우 데모 발급기관을 사용 설정하려면 플래그를 사용하여 Chrome을 실행해야 합니다. (데모에서 제공되는 안내 참고) 페이지 참조).

이 데모를 실행하면 브라우저에서 데모 발급기관과 사용자를 사용하는 것입니다. 토큰을 제공하고 소비할 수 있습니다

기술적 고려사항

데모는 다음 단계를 구현할 때 가장 잘 실행됩니다.

플래그를 사용하여 Chrome을 실행하기 전에 모든 Chrome 인스턴스를 중지해야 합니다.
Windows 컴퓨터에서 실행 중인 경우 이 가이드에 설명된 대로 을 참조하세요.
응용 프로그램 > 스토리지 > 비공개 상태 토큰: 데모 애플리케이션을 사용하는 동안 발행/사용된 토큰 확인 데모 발급기관에서 확인할 수 있습니다

채택 설정

발급기관 되기

발급기관은 PST에서 핵심적인 역할을 합니다. 토큰에 값을 할당하여 사용자의 봇인지 여부 발급기관으로서 PST를 시작하려면 이 과정을 완료한 다음 발급기관 등록 프로세스.

발급기관이 되려면 발급기관 웹사이트 운영자가 문제(GitHub) 새 PST를 사용하여 저장소를 발급기관' 있습니다. 저장소의 안내에 따라 문제를 작성합니다. 엔드포인트가 확인되면 이 저장소로 병합되고 Chrome 서버 측 인프라에서 이러한 키를 가져오기 시작합니다.

발급기관 서버

발급자와 패스백은 PST의 핵심 행위자입니다. 서버 및 토큰은 사용할 수 있습니다. 이미 토큰과 GitHub 문서에서 PST 서버에 대한 자세한 내용 제공 PST 발급기관으로 설정하려면 다음이 필요합니다. 먼저 발급 서버를 설정합니다

환경 배포: 발급기관 서버

토큰 발급기관 서버를 구현하려면 자체 서버 측을 빌드해야 합니다. HTTP 엔드포인트를 노출하는 애플리케이션입니다.

발급기관 구성요소는 두 가지 기본 모듈로 구성됩니다. (1) 발급기관 서버 (2) 토큰 발급기관

모든 웹 페이싱 애플리케이션과 마찬가지로 추가적인 보호 계층을 권장합니다. 발급자 서버에 전달됩니다

발급자 서버: 이 예제 구현에서 발급 서버는 Node.js 서버는 Express 프레임워크를 사용하여 발급기관 HTTP 엔드포인트입니다. GitHub의 샘플 코드를 확인할 수 있습니다.
토큰 발급기관: 발급기관 암호화 구성요소는 이 구성요소의 성능 요구사항으로 인해 한 예로 보링(Boring)'과 SSL 라이브러리를 사용하여 토큰을 관리할 수 있습니다. 발급자 코드 예와 설치에 대한 자세한 정보를 찾을 수 있습니다. (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"
      }
    });

코드 예 보기

사용자 서버

자체 API를 빌드하여 토큰 사용 서비스를 구현해야 합니다. 애플리케이션을 배포할 수 있습니다 이렇게 하면 발급기관에서 전송하는 토큰을 읽을 수 있습니다. 전송합니다. 다음 단계에서는 토큰 사용 방법과 해당 토큰과 연결된 상환 기록

발급기관과 사용자를 동일한 서버 (또는 합니다.

사용자 서버 구성요소 — PST 데모 구성요소: 리더 서버의 기본 구성요소입니다. 사용자 서버 (Node.js 애플리케이션) 및 토큰 사용자 (사용 과정에서 서명과 토큰을 확인하는 암호화 구성요소)

등록자 서버의 기술 요구사항

프로토콜에 따라 두 개 이상의 HTTP 엔드포인트를 구현하여 신청자 서버:

/.well-known/private-state-token/redemption: 모든 엔드포인트가 토큰 사용이 처리됩니다. 이 엔드포인트는 토큰 사용자 구성요소가 <ph type="x-smartling-placeholder">
- 예시 코드

사용자 서버에 호출 보내기

토큰을 사용하려면 웹사이트 가져오기 호출을 구현하여 전에 발행된 토큰을 사용할 수 있습니다.

    // 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명 이하: 다음의 경우 문제 해결을 간소화해야 함 발생할 수 있습니다

권한 정책

제대로 작동하려면 최상위 페이지 및 API를 사용하는 모든 하위 리소스에서 PST API를 사용할 수 있어야 합니다.

토큰 요청 작업은 private-state-token-issuance 지시어에 의해 제어됩니다. token-redemption 및 send-redemption-record 작업은 private-state-token-redemption 지시어에 의해 제어됩니다. 기본적으로 이러한 지시어의 허용 목록은 self로 설정됩니다. 즉, 이 기능은 최상위 페이지 (및 동일 출처 iframe)에서만 사용할 수 있으며 페이지에서 명시적으로 위임하지 않는 한 교차 출처 iframe에서는 사용할 수 없습니다.

각 페이지의 Permissions-Policy 헤더에 private-state-token-issuance=() 및 private-state-token-redemption=()를 포함하여 사이트의 특정 페이지에 대한 PST 토큰 발급 또는 사용을 선택 해제할 수 있습니다.

Permissions-Policy 헤더를 사용하여 PST에 대한 서드 파티 액세스를 제어할 수도 있습니다. 헤더 출처 목록의 매개변수로 self 및 API에 대한 액세스를 허용하려는 모든 출처를 사용합니다. 예를 들어 자체 출처와 https://example.com를 제외한 모든 탐색 컨텍스트에서 PST를 완전히 사용 중지하려면 다음 HTTP 응답 헤더를 설정합니다.

Permissions-Policy:private-state-token-issuance=(self "https://example.com"),private-state-token-redemption=(self "https://example.com")

모든 교차 출처 리소스에 API를 사용 설정하려면 출처 목록을 *로 설정하세요.

권한 정책으로 개인 정보 보호 샌드박스 기능을 제어하는 방법을 알아보거나 권한 정책을 자세히 알아보세요.

문제 해결

Chrome DevTools 네트워크 및 애플리케이션 탭에서 PST를 검사할 수 있습니다.

네트워크 탭에서 다음을 수행합니다.

Network 탭의 DevTools 검사 — PST용 DevTools 검사: **네트워크**로 이동합니다. **비공개 상태 토큰**: 특정 페이지의 토큰 및 발급기관에 관한 모든 관련 정보를 가져옵니다.

애플리케이션 탭에서 다음을 수행합니다.

Application 탭의 DevTools 검사 — PST용 DevTools 검사: 애플리케이션으로 이동 > 비공개 상태 토큰을 사용해 특정 페이지의 토큰 및 발급기관에 관한 모든 관련 정보를 가져옵니다.

자세히 알아보기 DevTools 통합.

고객 권장사항

웹사이트의 중요 기능이 특정 토큰 발급기관에 달려 있다면 해당 기능의 우선순위를 지정합니다. 다른 스크립트를 로드하기 전에 이러한 기본 발급기관에 hasPrivateToken(issuer)를 호출합니다. 이는 잠재적인 사용 실패를 방지하는 데 중요합니다.

최상위 수준별 발급기관 수는 2개로 제한되며 서드 파티 스크립트에서도 hasPrivateToken(issuer)를 호출하여 선호하는 발급기관의 우선순위를 정할 수도 있습니다. 따라서 사이트가 제대로 작동할 수 있도록 필수 발급기관의 보안을 먼저 강화해야 합니다.

  // Prioritize your critical token issuer.
  document.hasPrivateToken('https://critical-issuer.example')
    .then(hasToken => {
      if (hasToken) {
        // Use the token or perform actions based on its availability.
      } else {
        // Handle the case where the token is not available.
      }
    });

  // Load third-party scripts or secure another token issuer (up to two in total).

서버 권장사항 및 문제 해결

발급자 및 등록자 서버가 효과적으로 운영될 수 있도록 혹시 모를 문제가 발생하지 않도록 액세스, 보안, 로깅 또는 트래픽 문제를 해결할 수 있습니다.

엔드포인트에서 TLS 1.3 또는 1.2를 사용하여 강력한 암호화를 적용해야 합니다.
인프라는 변동이 심한 트래픽 볼륨을 처리할 준비가 되어 있어야 합니다. (급증 포함)
키가 액세스 권한에 맞게 안전하게 보호되고 있는지 확인하세요. 정책, 키 관리 전략 및 업무 연속성 계획을 제어합니다.
스택에 관측 가능성 측정항목을 추가하여 사용량, 병목 현상 및 성능 문제를 파악할 수 있는 가시성 살펴봤습니다

추가 정보

개발자 문서 검토: <ph type="x-smartling-placeholder">
1. 먼저 개요 PST와 그 기능에 대해 빠르게 숙지하세요.
2. PST 소개 동영상을 시청하세요.
3. PST 데모 사용해 보기
4. API 읽기 설명을 참조하세요. 파악할 수 있습니다.
5. 현재 사양을 참조하세요.
GitHub를 통해 대화에 참여합니다. 문제 또는 W3C 호출을 참조하세요.
용어를 더 잘 이해하려면 개인 정보 보호 샌드박스 용어집.
'오리진 트라이얼'과 같은 Chrome 개념에 관해 자세히 알아보기 또는 'Chrome 신고'에서는 goo.gle/cc