Cookie của bên thứ ba có thể bị chặn do các hạn chế của trình duyệt, chế độ cài đặt của người dùng, cờ của nhà phát triển hoặc chính sách của doanh nghiệp.
Bạn cần trang web hoặc dịch vụ của mình mang đến trải nghiệm tuyệt vời cho tất cả người dùng, dù có hay không có cookie của bên thứ ba.
Trên trang này, bạn sẽ tìm thấy thông tin về những trường hợp nhận dạng có khả năng bị ảnh hưởng nhiều nhất, cũng như thông tin tham khảo về các giải pháp có thể.
Nếu trang web của bạn chỉ xử lý các luồng trong cùng một miền và miền con, chẳng hạn như publisher.example và login.publisher.example, thì trang web đó sẽ không sử dụng cookie trên nhiều trang web và luồng đăng nhập của bạn dự kiến sẽ không bị ảnh hưởng bởi các thay đổi về cookie của bên thứ ba.
Tuy nhiên, nếu trang web của bạn sử dụng một miền riêng biệt để đăng nhập, chẳng hạn như Đăng nhập bằng Google hoặc Đăng nhập bằng Facebook, hoặc trang web của bạn cần chia sẻ thông tin xác thực người dùng trên nhiều miền hoặc miền con, thì có thể bạn sẽ cần thực hiện các thay đổi đối với trang web của mình để đảm bảo quá trình chuyển đổi diễn ra suôn sẻ khi không sử dụng cookie trên nhiều trang web.
Hành trình phổ biến của người dùng
Trước đây, nhiều quy trình về danh tính dựa vào cookie của bên thứ ba. Bảng này liệt kê một số hành trình phổ biến của người dùng và các giải pháp tiềm năng cho từng hành trình không phụ thuộc vào cookie của bên thứ ba. Các phần sau đây sẽ giải thích lý do đưa ra những đề xuất này.
Các API thay thế được đề xuất cho các trường hợp sử dụng phổ biến
trong bảng đang ở giai đoạn đầu phát triển. Ý kiến phản hồi của bạn rất có giá trị và sẽ giúp định hình tương lai của họ. Hãy chia sẻ ý kiến của bạn về những API này: Partitioned Popins (Pop-in được phân vùng).
| Hành trình của người dùng | Các API được đề xuất |
|---|---|
| Đăng nhập bằng tài khoản mạng xã hội |
Đối với nhà cung cấp danh tính: triển khai FedCM Đối với các bên tin cậy: liên hệ với nhà cung cấp danh tính của bạn |
|
Đối với nhà cung cấp danh tính hoặc giải pháp tuỳ chỉnh: Bộ trang web có liên quan |
|
| Quản lý hồ sơ người dùng |
Storage Access API Related Website Sets CHIPS FedCM + SAA |
|
Storage Access API Related Website Sets CHIPS FedCM + SAA |
|
| Xác thực |
Storage Access API FedCM Web Authentication API sciencePartitioned Popins |
| Các trường hợp này thường không có sự phụ thuộc vào cookie của bên thứ ba và dự kiến sẽ không bị ảnh hưởng. |
Kiểm thử hành trình của người dùng liên quan đến danh tính
Cách tốt nhất để kiểm tra xem quy trình đăng nhập của bạn có bị ảnh hưởng bởi các thay đổi về cookie của bên thứ ba hay không là thực hiện quy trình đăng ký, khôi phục mật khẩu, đăng nhập và đăng xuất khi cờ kiểm thử cookie của bên thứ ba được bật.
Đây là danh sách kiểm tra những việc cần kiểm tra sau khi bạn hạn chế cookie của bên thứ ba:
- Đăng ký người dùng: Việc tạo tài khoản mới diễn ra như dự kiến. Nếu sử dụng nhà cung cấp danh tính bên thứ ba, hãy kiểm tra để đảm bảo rằng việc đăng ký tài khoản mới hoạt động cho mọi hoạt động tích hợp.
- Khôi phục mật khẩu: Quá trình khôi phục mật khẩu diễn ra như dự kiến, từ giao diện người dùng web, đến CAPTCHA, đến việc nhận được email khôi phục mật khẩu.
- Đăng nhập: Quy trình đăng nhập hoạt động trong cùng một miền và khi chuyển đến các miền khác. Hãy nhớ kiểm thử mọi quy trình tích hợp tính năng đăng nhập.
- Đăng xuất: Quy trình đăng xuất hoạt động như dự kiến và người dùng vẫn đăng xuất sau quy trình đăng xuất.
Bạn cũng nên kiểm thử để đảm bảo các tính năng khác của trang web yêu cầu người dùng đăng nhập vẫn hoạt động mà không cần cookie trên nhiều trang web, đặc biệt là nếu các tính năng đó liên quan đến việc tải tài nguyên trên nhiều trang web. Ví dụ: nếu bạn sử dụng CDN để tải hình ảnh hồ sơ người dùng, hãy đảm bảo rằng việc này vẫn hoạt động. Nếu bạn có các hành trình quan trọng của người dùng, chẳng hạn như thanh toán, được kiểm soát bằng một lần đăng nhập, hãy đảm bảo rằng các hành trình này vẫn hoạt động.
Giải pháp đăng nhập
Trong phần này, bạn sẽ tìm thấy thông tin cụ thể hơn về cách những quy trình đó có thể bị ảnh hưởng.
Đăng nhập một lần (SSO) của bên thứ ba
Tính năng đăng nhập một lần (SSO) của bên thứ ba cho phép người dùng xác thực bằng một bộ thông tin đăng nhập duy nhất trên một nền tảng, sau đó truy cập vào nhiều ứng dụng và trang web mà không cần phải nhập lại thông tin đăng nhập. Do sự phức tạp của việc triển khai giải pháp SSO, nhiều công ty chọn sử dụng nhà cung cấp giải pháp bên thứ ba để chia sẻ trạng thái đăng nhập giữa nhiều nguồn. Ví dụ về nhà cung cấp bao gồm Okta, Ping Identity, Google Cloud IAM hoặc Microsoft Entra ID.
Nếu giải pháp của bạn dựa vào một nhà cung cấp bên thứ ba, thì có thể bạn cần thực hiện một số thay đổi nhỏ, chẳng hạn như nâng cấp thư viện. Cách tiếp cận tốt nhất là tìm kiếm hướng dẫn từ nhà cung cấp về cách các phần phụ thuộc cookie của bên thứ ba ảnh hưởng đến giải pháp và cách tiếp cận mà họ đề xuất cho dịch vụ của mình. Một số nhà cung cấp sẽ âm thầm di chuyển khỏi cookie của bên thứ ba, trong trường hợp này, các bên phụ thuộc không cần cập nhật.
Nhiều tên miền
Một số trang web chỉ sử dụng một miền khác để xác thực những người dùng không đủ điều kiện sử dụng cookie same-site, chẳng hạn như một trang web sử dụng example.com cho trang web chính và login.example cho quy trình đăng nhập. Điều này có thể yêu cầu truy cập vào cookie của bên thứ ba để đảm bảo rằng người dùng được xác thực trên cả hai miền.
Một số doanh nghiệp có thể có nhiều sản phẩm được lưu trữ trên các miền hoặc miền con khác nhau. Những giải pháp như vậy có thể muốn chia sẻ phiên người dùng trên các sản phẩm đó, một trường hợp có thể yêu cầu truy cập vào cookie của bên thứ ba giữa nhiều miền.
Các phương án di chuyển có thể có cho trường hợp này là:
- Cập nhật để sử dụng cookie của bên thứ nhất ("same-site"): Thay đổi cơ sở hạ tầng trang web để quy trình đăng nhập được lưu trữ trên cùng một miền (hoặc miền con) với trang web chính, chỉ sử dụng cookie của bên thứ nhất. Điều này có thể đòi hỏi nhiều công sức hơn, tuỳ thuộc vào cách thiết lập cơ sở hạ tầng.
- Sử dụng Bộ trang web có liên quan (RWS) và Storage Access API (SAA): RWS cho phép truy cập hạn chế vào cookie trên nhiều trang web giữa một nhóm nhỏ các miền có liên quan. Với RWS, bạn không cần lời nhắc người dùng khi yêu cầu quyền truy cập vào bộ nhớ bằng Storage Access API. Điều này cho phép SSO trên những RP nằm trong cùng một RWS với IdP. Tuy nhiên, RWS chỉ hỗ trợ quyền truy cập vào cookie trên nhiều trang web trên một số lượng miền có hạn.
- Sử dụng Web Authentication API: Web Authentication API cho phép các bên phụ thuộc (RP) đăng ký một nhóm nhỏ các nguồn gốc có liên quan mà thông tin đăng nhập có thể được tạo và sử dụng.
- Nếu bạn đang xác thực người dùng trên hơn 5 miền được liên kết, hãy khám phá Federated Credentials Management (FedCM): FedCM cho phép nhà cung cấp dịch vụ danh tính dựa vào Chrome để xử lý các luồng liên quan đến danh tính mà không yêu cầu cookie của bên thứ ba. Trong trường hợp của bạn, "miền đăng nhập" có thể đóng vai trò là nhà cung cấp dịch vụ danh tính FedCM và được dùng để xác thực người dùng trên các miền khác của bạn.
Xác thực từ nội dung được nhúng
Giả sử một iframe 3-party-app.example được nhúng trên top-level.example. Trên 3-party-app.example, người dùng có thể đăng nhập bằng thông tin đăng nhập 3-party-app.example hoặc bằng một nhà cung cấp bên thứ ba khác.
Người dùng nhấp vào "đăng nhập" và xác thực trong cửa sổ bật lên 3-party-app.example. Cửa sổ bật lên 3-party-app.example sẽ đặt cookie của bên thứ nhất. Tuy nhiên, iframe 3-party-app.example được nhúng trên top-level.example sẽ được phân vùng và không thể truy cập vào cookie được đặt trong bối cảnh bên thứ nhất trên 3-party-app.example.
Vấn đề tương tự sẽ xảy ra khi người dùng được chuyển hướng từ top-level.example đến 3-party-app.example rồi quay lại. Cookie được ghi trong ngữ cảnh bên thứ nhất của trang web 3-party-app.example, nhưng được phân vùng và không thể truy cập trong iframe 3-party-app.example.
Trong trường hợp người dùng đã truy cập vào nguồn gốc được nhúng trong một bối cảnh cấp cao nhất, Storage Access API là một giải pháp phù hợp.
Để di chuyển khỏi các giải pháp dựa vào cookie của bên thứ ba, các nhà cung cấp dịch vụ danh tính nên sử dụng FedCM API và FedCM được gọi từ bên trong các thành phần nhúng thay vì cửa sổ bật lên.
Một giải pháp khác được đề xuất cho quy trình này là Partitioned Popins (Popin được phân vùng) đang được triển khai.
Đăng nhập qua mạng xã hội
Các nút đăng nhập như Đăng nhập bằng Google, Đăng nhập bằng Facebook và Đăng nhập bằng Twitter là dấu hiệu rõ ràng cho thấy trang web của bạn đang sử dụng một nhà cung cấp danh tính liên kết. Mỗi nhà cung cấp danh tính liên kết sẽ có cách triển khai riêng.
Nếu đang sử dụng Thư viện nền tảng JavaScript sử dụng tính năng đăng nhập bằng Google không được dùng nữa, bạn có thể tìm thông tin về cách di chuyển sang thư viện Dịch vụ nhận dạng của Google mới hơn để xác thực và uỷ quyền.
Hầu hết các trang web sử dụng thư viện Dịch vụ nhận dạng của Google mới đều đã loại bỏ sự phụ thuộc vào cookie của bên thứ ba, vì thư viện sẽ di chuyển âm thầm để sử dụng FedCM cho khả năng tương thích. Bạn nên kiểm thử trang web của mình khi bật cờ kiểm thử giai đoạn loại bỏ cookie của bên thứ ba và nếu cần, hãy sử dụng danh sách kiểm tra di chuyển FedCM để chuẩn bị.
Truy cập và sửa đổi dữ liệu người dùng từ các thành phần được nhúng
Nội dung được nhúng thường được dùng cho hành trình của người dùng, chẳng hạn như truy cập hoặc quản lý dữ liệu hồ sơ người dùng hoặc dữ liệu về gói thuê bao.
Ví dụ: người dùng có thể đăng nhập vào website.example, nơi nhúng một tiện ích subscriptions.example. Tiện ích này cho phép người dùng quản lý dữ liệu của họ, chẳng hạn như đăng ký nội dung trả phí hoặc cập nhật thông tin thanh toán. Để sửa đổi dữ liệu người dùng, tiện ích được nhúng có thể cần truy cập vào cookie của chính nó trong khi được nhúng trên website.example. Trong trường hợp dữ liệu này phải được tách biệt với website.example, CHIPS có thể giúp đảm bảo rằng thành phần nhúng có thể truy cập vào thông tin cần thiết. Với CHIPS, tiện ích subscriptions.example được nhúng trên website.example sẽ không có quyền truy cập vào dữ liệu đăng ký của người dùng trên các trang web khác.
Hãy xem xét một trường hợp khác: một video trên streaming.example được nhúng trên website.example và người dùng có gói thuê bao cao cấp streaming.example. Tiện ích cần biết thông tin này để tắt quảng cáo. Nếu cần truy cập vào cùng một cookie trên nhiều trang web, hãy cân nhắc sử dụng Storage Access API nếu người dùng đã truy cập vào streaming.example dưới dạng cấp cao nhất và Bộ trang web có liên quan nếu bộ website.example sở hữu streaming.example.
Kể từ Chrome 131, FedCM sẽ được tích hợp với Storage Access API. Với chế độ tích hợp này, khi người dùng chấp nhận lời nhắc FedCM, trình duyệt sẽ cấp cho IdP nhúng quyền truy cập vào bộ nhớ không phân vùng.
Để biết thêm thông tin về API cần chọn để xử lý một hành trình cụ thể của người dùng bằng nội dung được nhúng, hãy xem Hướng dẫn về nội dung được nhúng.
Hành trình khác của người dùng
Những hành trình của người dùng không phụ thuộc vào cookie của bên thứ ba sẽ không bị ảnh hưởng bởi các thay đổi về cách Chrome xử lý cookie của bên thứ ba. Các giải pháp hiện có, chẳng hạn như đăng nhập, đăng xuất hoặc khôi phục tài khoản trong bối cảnh bên thứ nhất, 2FA, sẽ hoạt động như dự kiến. Các điểm có thể bị hỏng đã được mô tả trước đây. Để biết thêm thông tin về một API cụ thể, hãy xem trang trạng thái API.
Kiểm tra trang web của bạn
Nếu trang web của bạn triển khai một trong những hành trình của người dùng được mô tả trong hướng dẫn này, bạn cần đảm bảo trang web của bạn đã sẵn sàng: kiểm tra trang web của bạn để biết mức sử dụng cookie của bên thứ ba, kiểm tra lỗi và chuyển sang các giải pháp được đề xuất.