Trước đây, cookie của bên thứ ba được dùng để lưu trữ và truyền tải thông tin về trạng thái của người dùng, chẳng hạn như trạng thái đăng nhập, thông tin về thiết bị mà họ đang sử dụng hoặc liệu họ có được biết và tin cậy hay không. Ví dụ: liệu người dùng có đăng nhập bằng SSO hay không, liệu người dùng có một loại thiết bị tương thích nhất định hay không hoặc liệu người dùng có được biết và tin cậy hay không. Do ngừng hỗ trợ cookie của bên thứ ba, nhiều trường hợp sử dụng này sẽ cần được hỗ trợ bằng các phương thức khác.
Mã thông báo trạng thái riêng tư cung cấp một cách để chia sẻ thông tin trên web, nhưng theo cách bảo vệ quyền riêng tư thông qua các chế độ kiểm soát lượng dữ liệu thực sự có thể được chia sẻ.
Mã thông báo trạng thái riêng tư (trước đây gọi là Mã thông báo tin cậy) cho phép truyền niềm tin về tính xác thực của người dùng từ ngữ cảnh này sang ngữ cảnh khác, đồng thời giúp các trang web chống lại hành vi gian lận và phân biệt bot với người dùng thực sự mà không cần theo dõi thụ động.
Tài liệu này trình bày thông tin chi tiết về kỹ thuật để triển khai Mã thông báo trạng thái riêng tư (PST). Để biết thêm thông tin tổng quan ở cấp cao, hãy xem nội dung Tổng quan về PST.
Mã thông báo trạng thái riêng tư hoạt động như thế nào?
Mối quan hệ chính cần hiểu trong PST là giữa bên phát hành và bên sử dụng. Bên phát hành và bên sử dụng có thể thuộc cùng một công ty.
- Đơn vị phát hành – Các thực thể này có một số tín hiệu về người dùng (ví dụ: liệu người dùng đó có phải là bot hay không) và nhúng tín hiệu đó vào một mã thông báo được lưu trữ trên thiết bị của người dùng (xem thêm thông tin chi tiết trong các phần tiếp theo).
- Người sử dụng mã thông báo – Các thực thể này có thể không có tín hiệu về người dùng nhưng cần biết một số thông tin về họ (ví dụ: người dùng đó có phải là bot hay không) và yêu cầu sử dụng mã thông báo của bên phát hành để hiểu mức độ đáng tin cậy của người dùng đó.
Mọi lượt tương tác với PST đều yêu cầu bên phát hành và bên sử dụng cùng nhau chia sẻ các tín hiệu trên web. Những tín hiệu đó là các giá trị thô không đủ chi tiết để xác định cá nhân.
Mã thông báo trạng thái riêng tư có phù hợp với tôi không?
Các công ty đang đưa ra quyết định về sự tin cậy và muốn có thông tin đó trên nhiều ngữ cảnh có thể hưởng lợi từ PST. Để biết thêm về các trường hợp sử dụng tiềm năng của tệp PST, hãy xem tài liệu của chúng tôi về các trường hợp sử dụng tệp PST.
Phát hành và sử dụng mã thông báo
Quá trình triển khai PST diễn ra theo 3 giai đoạn:
- Phát hành mã thông báo
- Sử dụng mã thông báo
- Chuyển tiếp bản ghi sử dụng
Trong giai đoạn đầu tiên, mã thông báo được cấp cho trình duyệt (thường là sau một số loại xác thực). Trong giai đoạn thứ hai, một thực thể khác sẽ đưa ra yêu cầu sử dụng mã thông báo đã được phát hành để đọc giá trị trong mã thông báo đó. Trong giai đoạn cuối cùng, bên sử dụng mã sẽ nhận được bản ghi sử dụng mã (RR) có giá trị được chứa trong mã thông báo. Sau đó, bên sử dụng mã đó có thể dùng bản ghi đó làm tài liệu chứng thực người dùng đó cho nhiều mục đích.
Xác định chiến lược mã thông báo
Để xác định chiến lược mã thông báo, bạn cần hiểu các khái niệm chính về PST (mã thông báo và bản ghi sử dụng), các biến, hành vi và giới hạn để có thể nghĩ đến cách sử dụng tiềm năng của các khái niệm đó cho trường hợp sử dụng của bạn.
Mã thông báo và bản ghi sử dụng: mối quan hệ giữa chúng là gì?
Mỗi thiết bị có thể lưu trữ tối đa 500 mã thông báo cho mỗi trang web cấp cao nhất và mỗi tổ chức phát hành. Ngoài ra, mỗi mã thông báo đều có siêu dữ liệu cho biết khoá mà bên phát hành đã dùng để phát hành mã thông báo đó. Thông tin đó có thể được dùng để quyết định có sử dụng mã thông báo hay không trong quá trình sử dụng. Dữ liệu PST được trình duyệt lưu trữ nội bộ trên thiết bị của người dùng và chỉ có thể được truy cập bằng API PST.
Khi một mã thông báo được sử dụng, Bản ghi sử dụng (RR) sẽ được lưu trữ trên thiết bị. Bộ nhớ này đóng vai trò là bộ nhớ đệm cho các lần sử dụng sau này. Mỗi thiết bị, trang và bên phát hành chỉ được sử dụng 2 mã thông báo mỗi 48 giờ. Các lệnh gọi sử dụng mã thưởng mới sẽ sử dụng các RR được lưu trong bộ nhớ đệm nếu có thể, thay vì gửi yêu cầu đến đơn vị phát hành.
- Mã thông báo mới được phát hành (tối đa 500 mã thông báo cho mỗi tổ chức phát hành, trang web và thiết bị).
- Tất cả mã thông báo đều được lưu trữ trong kho mã thông báo trên thiết bị (tương tự như kho cookie).
- Nếu không tìm thấy RR nào đang hoạt động, thì bạn có thể tạo RR mới sau khi phát hành (tối đa 2 RR mỗi 48 giờ).
- RR được coi là đang hoạt động cho đến khi hết hạn và sẽ được dùng làm bộ nhớ đệm cục bộ.
- Các lệnh gọi sử dụng mới sẽ truy cập vào bộ nhớ đệm cục bộ (không tạo RR mới).
Sau khi xác định trường hợp sử dụng, bạn phải xác định cẩn thận thời gian hoạt động của RR vì điều này sẽ xác định số lần bạn có thể sử dụng các RR đó trong trường hợp của mình.
Hãy đảm bảo bạn hiểu rõ các hành vi và biến quan trọng sau đây trước khi xác định chiến lược:
| Biến / hành vi | Mô tả | Mục đích sử dụng tiềm năng |
|---|---|---|
| Siêu dữ liệu khoá mã thông báo | Mỗi mã thông báo có thể được phát hành bằng một và chỉ một khoá mã hoá. Trong PST, mỗi bên phát hành có giới hạn là 6 khoá. | Một cách tiềm năng để sử dụng biến này là xác định phạm vi tin cậy cho mã thông báo dựa trên khoá mã hoá (ví dụ: khoá 1 = độ tin cậy cao trong khi khoá 6 = không tin cậy). |
| Ngày hết hạn mã thông báo | Ngày hết hạn mã thông báo giống với ngày hết hạn khoá. | Bạn có thể xoay vòng khoá ít nhất 60 ngày một lần và tất cả mã thông báo được phát hành bằng khoá không hợp lệ cũng được coi là không hợp lệ. |
| Giới hạn số lần sử dụng mã thông báo | Mỗi thiết bị và mỗi bên phát hành có giới hạn 2 lượt sử dụng mã thông báo mỗi 48 giờ. | Tuỳ thuộc vào số lượt sử dụng ước tính mà trường hợp sử dụng của bạn yêu cầu mỗi 48 giờ. |
| Số lượng tổ chức phát hành tối đa cho mỗi nguồn gốc cấp cao nhất | Số lượng tổ chức phát hành tối đa trên mỗi nguồn gốc cấp cao nhất hiện là 2. | Hãy xác định kỹ bên phát hành của mỗi trang. |
| Mã thông báo cho mỗi tổ chức phát hành trên một thiết bị | Số lượng mã thông báo tối đa cho mỗi tổ chức phát hành trên một thiết bị cụ thể hiện là 500. | Đảm bảo số lượng mã thông báo của mỗi bên phát hành không vượt quá 500. Hãy nhớ xử lý các lỗi trong trang web khi cố gắng phát hành mã thông báo. |
| Xoay vòng cam kết về khoá | Mọi nhà phát hành PST đều phải hiển thị một điểm cuối có các cam kết chính có thể thay đổi 60 ngày một lần và mọi lượt xoay nhanh hơn thời gian đó sẽ bị bỏ qua. | Nếu khoá của bạn sắp hết hạn trong vòng chưa đến 60 ngày, bạn bắt buộc phải cập nhật các cam kết về khoá trước ngày đó để tránh bị gián đoạn (xem thông tin chi tiết). |
| Vòng đời của bản ghi lượt sử dụng | Bạn có thể xác định thời gian tồn tại của RR để xác định ngày hết hạn. Vì RR được lưu vào bộ nhớ đệm để tránh các lệnh gọi sử dụng mới không cần thiết đến đơn vị phát hành, nên điều này rất quan trọng để đảm bảo có đủ tín hiệu sử dụng mới. | Vì có giới hạn tỷ lệ sử dụng là 2 mã thông báo mỗi 48 giờ, nên bạn cần xác định thời gian hoạt động của RR để có thể thực thi thành công các lệnh gọi sử dụng trong ít nhất khoảng thời gian này (thời gian hoạt động của RR phải được đặt tương ứng). Bạn nên đặt thời lượng này theo thứ tự tuần. |
Các trường hợp ví dụ
Tình huống #1: Vòng đời của mã khuyến mãi là dưới 24 giờ (t=t) và người dùng sử dụng nhiều lần trong khoảng thời gian 48 giờ.
Tình huống #2: Vòng đời của mã khuyến mãi là 24 giờ và người dùng sử dụng mã nhiều lần trong khoảng thời gian 48 giờ.
Tình huống #3: Vòng đời của mã khuyến mãi là 48 giờ và người dùng sử dụng mã nhiều lần trong khoảng thời gian 48 giờ.
Chạy bản minh hoạ
Trước khi sử dụng PST, bạn nên thiết lập bản minh hoạ trước. Để dùng thử bản minh hoạ PST , bạn cần chạy Chrome bằng các cờ để bật các cam kết khoá của bên phát hành bản minh hoạ (làm theo hướng dẫn trên trang minh hoạ).
Khi chạy bản minh hoạ này, trình duyệt của bạn đang sử dụng máy chủ phát hành và máy chủ sử dụng mã thông báo của bản minh hoạ để cung cấp và sử dụng mã thông báo.
Những điểm cần lưu ý về mặt kỹ thuật
Bản minh hoạ sẽ chạy tốt nhất nếu bạn triển khai các bước sau:
- Hãy nhớ dừng tất cả các phiên bản Chrome trước khi chạy Chrome bằng cờ.
- Nếu bạn đang chạy trên máy Windows, hãy xem hướng dẫn này về cách truyền tham số đến tệp nhị phân thực thi của Chrome.
- Mở Công cụ của Chrome cho nhà phát triển trong phần Applications (Ứng dụng) > Storage (Bộ nhớ) > Private State Tokens (Mã thông báo trạng thái riêng tư) trong khi sử dụng ứng dụng minh hoạ để xem các mã thông báo do bên phát hành minh hoạ phát hành/đổi mã.
Thiết lập để sử dụng
Trở thành bên phát hành
Bên phát hành đóng vai trò quan trọng trong PST. Các thuật toán này chỉ định giá trị cho mã thông báo để xác định xem người dùng có phải là bot hay không. Nếu muốn bắt đầu sử dụng PST với tư cách là nhà phát hành, bạn cần đăng ký bằng cách hoàn tất quy trình đăng ký Nhà phát hành.
Để đăng ký trở thành tổ chức phát hành, nhà điều hành trang web của tổ chức phát hành phải mở một vấn đề mới trên kho lưu trữ GitHub bằng mẫu "Tổ chức phát hành PST mới". Làm theo hướng dẫn trên kho lưu trữ để điền thông tin về vấn đề. Sau khi được xác minh, điểm cuối sẽ được hợp nhất vào kho lưu trữ này và cơ sở hạ tầng phía máy chủ của Chrome sẽ bắt đầu tìm nạp các khoá đó.
Máy chủ của tổ chức phát hành
Bên phát hành và bên sử dụng là các bên đóng vai trò chính trong PST; máy chủ và mã thông báo là các công cụ chính của PST. Mặc dù đã cung cấp một số thông tin chi tiết về mã thông báo và trong tài liệu trên GitHub, nhưng chúng tôi muốn cung cấp thêm thông tin chi tiết về máy chủ PST. Để thiết lập làm đơn vị phát hành PST, trước tiên, bạn cần thiết lập máy chủ phát hành.
Triển khai môi trường: máy chủ của tổ chức phát hành
Để triển khai máy chủ phát hành mã thông báo, bạn cần xây dựng ứng dụng phía máy chủ của riêng mình để hiển thị các điểm cuối HTTP.
Thành phần phát hành bao gồm hai mô-đun chính: (1) máy chủ phát hành và (2) trình phát hành mã thông báo.
Giống như tất cả các ứng dụng trên web, bạn nên thêm một lớp bảo vệ cho máy chủ của đơn vị phát hành.
Máy chủ phát hành: Trong ví dụ triển khai, máy chủ phát hành của chúng ta là một máy chủ Node.js sử dụng khung Express để lưu trữ các điểm cuối HTTP của Trình phát hành. Bạn có thể xem mã mẫu trên GitHub.
Bên phát hành mã thông báo: Thành phần mã hoá của bên phát hành không yêu cầu bất kỳ ngôn ngữ cụ thể nào, nhưng do các yêu cầu về hiệu suất của thành phần này, chúng tôi sẽ cung cấp ví dụ về cách triển khai C, sử dụng thư viện Boring SSL để quản lý mã thông báo. Bạn có thể tìm thấy ví dụ về mã của tổ chức phát hành và thêm thông tin về cách cài đặt trên GitHub
Khoá: Thành phần phát hành mã thông báo sử dụng khoá EC tuỳ chỉnh để mã hoá mã thông báo. Các khoá này phải được bảo vệ và lưu trữ trong bộ nhớ bảo mật.
Yêu cầu kỹ thuật đối với máy chủ của tổ chức phát hành
Theo giao thức, bạn sẽ cần triển khai ít nhất 2 điểm cuối HTTP trong máy chủ của tổ chức phát hành:
- Cam kết khoá (ví dụ:
/.well-known/private-state-token/key-commitment): Điểm cuối này là nơi trình duyệt có thể xem thông tin chi tiết về khoá công khai mã hoá để xác nhận rằng máy chủ của bạn là hợp lệ. - Phát hành mã thông báo (ví dụ:
/.well-known/private-state-token/issuance): Điểm cuối phát hành mã thông báo nơi tất cả yêu cầu mã thông báo sẽ được xử lý. Điểm cuối này sẽ là điểm tích hợp cho thành phần phát hành mã thông báo.
Như đã đề cập trước đó, do lưu lượng truy cập dự kiến cao mà máy chủ này có thể xử lý, bạn nên triển khai máy chủ này bằng một cơ sở hạ tầng có thể mở rộng (ví dụ: trong môi trường đám mây) để có thể điều chỉnh phần phụ trợ dựa trên nhu cầu thay đổi.
Gửi lệnh gọi đến máy chủ của tổ chức phát hành
Triển khai lệnh gọi tìm nạp trang web đến ngăn xếp trình phát hành để phát hành mã thông báo mới.
// issuer request
await fetch("/.well-known/private-state-token/issuance", {
method: "POST",
privateToken: {
version: 1,
operation: "token-request"
}
});
Máy chủ của trình sử dụng mã
Bạn sẽ cần triển khai dịch vụ sử dụng mã thông báo bằng cách tạo ứng dụng phía máy chủ của riêng mình. Điều này cho phép bạn đọc các mã thông báo mà bên phát hành gửi. Các bước sau đây trình bày cách sử dụng mã thông báo cũng như cách đọc bản ghi sử dụng mã thông báo được liên kết với các mã thông báo đó.
Bạn có thể chọn chạy trình phát hành và trình sử dụng trong cùng một máy chủ (hoặc nhóm máy chủ).
Yêu cầu kỹ thuật đối với máy chủ của người sử dụng mã
Theo giao thức, bạn sẽ cần triển khai ít nhất hai điểm cuối HTTP cho máy chủ của trình sử dụng mã thưởng:
/.well-known/private-state-token/redemption: điểm cuối nơi tất cả các lượt sử dụng mã thông báo sẽ được xử lý. Điểm cuối này sẽ là nơi tích hợp thành phần sử dụng mã thông báo
Gửi lệnh gọi đến máy chủ của người sử dụng
Để sử dụng mã thông báo, bạn cần triển khai lệnh gọi tìm nạp trang web đến ngăn xếp trình sử dụng mã thông báo để sử dụng mã thông báo đã phát hành trước đó.
// redemption request
await fetch("/.well-known/private-state-token/redemption", {
method: "POST",
privateToken: {
version: 1,
operation: "token-redemption",
refreshPolicy: "none"
}
});
Xem mã mẫu.
Sau khi sử dụng mã thông báo, bạn có thể gửi bản ghi sử dụng (RR) bằng cách thực hiện một lệnh gọi tìm nạp khác:
// 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>]
}
});
Xem mã mẫu.
Triển khai cách triển khai
Để kiểm thử quá trình triển khai, trước tiên, hãy chuyển đến trang web nơi lệnh gọi phát hành được thực hiện và xác nhận rằng(các) mã thông báo được tạo theo logic của bạn. Xác minh trong phần phụ trợ rằng các lệnh gọi được thực hiện theo thông số kỹ thuật. Sau đó, hãy chuyển đến trang web thực hiện lệnh gọi sử dụng mã và xác nhận rằng các RR đã được tạo theo logic của bạn.
Triển khai trong thực tế
Bạn nên chọn các trang web mục tiêu thuộc trường hợp sử dụng cụ thể của mình:
- Số lượt truy cập hằng tháng ở mức thấp (~ <1 triệu lượt truy cập/tháng): Bạn nên bắt đầu bằng cách triển khai API cho một nhóm đối tượng nhỏ
- Bạn sở hữu và kiểm soát: Nếu cần, bạn có thể nhanh chóng tắt tính năng triển khai mà không cần phê duyệt phức tạp
- Không quá một tổ chức phát hành: Để giới hạn số lượng mã thông báo nhằm đơn giản hoá quá trình kiểm thử.
- Không quá hai người sử dụng: Bạn cần đơn giản hoá việc khắc phục sự cố trong trường hợp xảy ra vấn đề.
Chính sách về quyền
Để hoạt động đúng cách, API PST phải có sẵn cho trang cấp cao nhất và mọi tài nguyên phụ sử dụng API.
Thao tác yêu cầu mã thông báo do lệnh private-state-token-issuance kiểm soát. Các thao tác token-redemption và send-redemption-record được kiểm soát bằng lệnh private-state-token-redemption. Trong Chrome 132 trở lên, danh sách cho phép của các lệnh này được đặt thành * (tất cả nguồn gốc) theo mặc định. Điều này có nghĩa là tính năng này có sẵn cho trang cấp cao nhất, các iframe cùng nguồn gốc và các iframe nhiều nguồn gốc mà không cần uỷ quyền rõ ràng.
Bạn có thể chọn không phát hành hoặc sử dụng mã thông báo PST cho một số trang cụ thể trên trang web của mình bằng cách thêm private-state-token-issuance=() và private-state-token-redemption=() vào tiêu đề Permissions-Policy (Chính sách quyền) cho mỗi trang.
Bạn cũng có thể sử dụng tiêu đề Permissions-Policy để kiểm soát quyền truy cập của bên thứ ba vào PST. Dùng self và mọi nguồn gốc mà bạn muốn cho phép truy cập vào API làm tham số cho danh sách nguồn gốc tiêu đề. Ví dụ: để tắt hoàn toàn việc sử dụng PST trong tất cả ngữ cảnh duyệt web ngoại trừ nguồn gốc của riêng bạn và https://example.com, hãy đặt các tiêu đề phản hồi HTTP sau:
Permissions-Policy:private-state-token-issuance=(self "https://example.com"),private-state-token-redemption=(self "https://example.com")
Để bật API cho tất cả tài nguyên trên nhiều nguồn gốc, hãy đặt danh sách nguồn gốc thành *.
Tìm hiểu cách kiểm soát các tính năng của Hộp cát về quyền riêng tư bằng Chính sách quyền hoặc tìm hiểu sâu hơn về Chính sách quyền.
Khắc phục sự cố
Bạn có thể kiểm tra PST từ thẻ Mạng và Ứng dụng trong Công cụ của Chrome cho nhà phát triển.
Trên thẻ Mạng:
Trên thẻ Ứng dụng:
Hãy đọc thêm về tính năng tích hợp DevTools này.
Các phương pháp hay nhất dành cho ứng dụng
Nếu các chức năng quan trọng của trang web phụ thuộc vào một số nhà phát hành mã thông báo nhất định, hãy ưu tiên những nhà phát hành đó. Gọi hasPrivateToken(issuer) cho các tổ chức phát hành ưu tiên này trước khi tải bất kỳ tập lệnh nào khác. Điều này rất quan trọng để ngăn chặn khả năng xảy ra lỗi khi sử dụng mã khuyến mãi.
Số lượng trình phát hành trên mỗi cấp cao nhất được giới hạn ở mức hai và tập lệnh của bên thứ ba cũng có thể cố gắng gọi hasPrivateToken(issuer) để ưu tiên các trình phát hành mà họ ưu tiên. Vì vậy, hãy bảo mật trước các nhà phát hành thiết yếu để đảm bảo trang web của bạn hoạt động như mong đợi.
// 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).
Các phương pháp hay nhất và cách khắc phục sự cố liên quan đến máy chủ
Để máy chủ của bên phát hành và bên sử dụng hoạt động hiệu quả, bạn nên triển khai các phương pháp hay nhất sau đây để đảm bảo không gặp phải vấn đề nào về quyền truy cập, bảo mật, ghi nhật ký hoặc lưu lượng truy cập cho PST.
- Các điểm cuối của bạn phải áp dụng phương thức mã hoá mạnh bằng cách sử dụng TLS 1.3 hoặc 1.2.
- Cơ sở hạ tầng của bạn phải sẵn sàng xử lý lưu lượng truy cập biến động (bao gồm cả lưu lượng truy cập tăng đột biến).
- Đảm bảo khoá của bạn được bảo vệ và an toàn, phù hợp với Chính sách kiểm soát quyền truy cập, Chiến lược quản lý khoá và Kế hoạch duy trì hoạt động kinh doanh liên tục.
- Thêm các chỉ số khả năng quan sát vào ngăn xếp để đảm bảo bạn có thể hiểu được mức sử dụng, nút thắt cổ chai và các vấn đề về hiệu suất sau khi chuyển sang phiên bản chính thức.
Thông tin khác
- Xem tài liệu dành cho nhà phát triển:
- Hãy bắt đầu bằng cách đọc phần tổng quan để nắm bắt nhanh PST và các tính năng của PST.
- Xem video giới thiệu về PST.
- Dùng thử bản minh hoạ về PST.
- Ngoài ra, hãy đọc nội dung giải thích về API này để hiểu thêm thông tin chi tiết.
- Đọc thêm về thông số kỹ thuật hiện tại của API.
- Đóng góp cho cuộc trò chuyện thông qua các vấn đề trên GitHub hoặc các lệnh gọi W3C.
- Để hiểu rõ hơn về bất kỳ thuật ngữ nào, hãy xem Bảng thuật ngữ về Hộp cát về quyền riêng tư.
- Để tìm hiểu thêm về các khái niệm của Chrome, chẳng hạn như "bản dùng thử theo nguyên gốc" hoặc "cờ Chrome", hãy xem các video ngắn và bài viết có tại goo.gle/cc.