Kiểm tra tác động của những thay đổi về cookie của bên thứ ba đối với quy trình đăng nhập của bạn

Chrome đang đề xuất một trải nghiệm mới để người dùng lựa chọn đối với cookie của bên thứ ba. Bạn cần chuẩn bị trang web của mình cho những người dùng chọn duyệt web mà không sử dụng cookie của bên thứ ba.

Trên trang này, bạn sẽ tìm thấy thông tin về các trường hợp danh tính có nhiều khả năng bị ảnh hưởng nhất, cũng như tham khảo các giải pháp có thể áp dụng.

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.examplelogin.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 để đăng nhập, chẳng hạn như với tính năng Đă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 thay đổi đối với trang web của mình để đảm bảo quá trình chuyển đổi từ cookie trên nhiều trang web diễn ra suôn sẻ.

Hành trình phổ biến của người dùng

Trước đây, nhiều quy trình làm việc về danh tính đều 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 cho các đề xuất này.

Hành trình của người dùng API được đề xuất
Đăng nhập bằng 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 phụ thuộc: liên hệ với nhà cung cấp danh tính của bạn
Đăng xuất khỏi Front Channel Đối với nhà cung cấp danh tính: triển khai FedCM

Đăng nhập một lần

Đối với nhà cung cấp danh tính hoặc giải pháp tuỳ chỉnh: Nhóm trang web có liên quan

Quản lý hồ sơ người dùng API Truy cập bộ nhớ
Bộ trang web có liên quan
CHIPS
FedCM

Quản lý gói thuê bao

API Truy cập bộ nhớ
Bộ trang web có liên quan
CHIPS
FedCM
Xác thực Storage Access API
FedCM
Web Authentication API
Trình bật lên được phân vùng

Các hành trình khác của người dùng

Những trường hợp này thường không có phần phụ thuộc cookie của bên thứ ba và dự kiến sẽ không bị ảnh hưởng.

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 bật cờ thử nghiệm cookie của bên thứ ba.

Sau đây là danh sách kiểm tra những điều 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 hoạt động như mong đợi. Nếu bạn sử dụng trì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 hoạt động như dự kiến, từ giao diện người dùng web, đến CAPTCHA, cho đến khi 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 quá trình tích hợp đă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 rằng 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 ảnh hồ sơ người dùng, hãy đảm bảo rằng thao tác này vẫn hoạt động. Nếu bạn có các hành trình trọng yếu của người dùng, chẳng hạn như thanh toán, được kiểm soát khi đăng nhập, hãy đảm bảo rằng các hành trình này tiếp tục 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ề mức độ ảnh hưởng của những luồ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 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 nhập lại thông tin đăng nhập. Do việc triển khai giải pháp SSO rất phức tạp, nên 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 gốc. Ví dụ về nhà cung cấp: 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 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 tốt nhất là bạn nên yêu cầu nhà cung cấp hướng dẫn về mức độ ảnh hưởng của các phần phụ thuộc cookie của bên thứ ba đối với 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ẽ tự động 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 cùng trang web, 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. Quy trình 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. Các giải pháp đó có thể cần chia sẻ phiên của người dùng trên các sản phẩm đó, trong trường hợp có thể yêu cầu quyền truy cập vào cookie của bên thứ ba giữa nhiều miền.

Các lộ trình di chuyển có thể áp dụng cho trường hợp này là:

  • Cập nhật để sử dụng cookie của bên thứ nhất ("cùng trang web"): 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. Trang web chính này sẽ chỉ sử dụng cookie của bên thứ nhất. Việc này có thể tốn 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 Nhóm trang web có liên quan (RWS)API truy cập bộ nhớ (SAA): RWS cho phép truy cập cookie trên nhiều trang web một cách hạn chế giữa một nhóm nhỏ các miền có liên quan. Với RWS, người dùng không cần phải nhắc họ khi yêu cầu quyền truy cập vào bộ nhớ bằng Storage Access API. Chế độ này cho phép đăng nhập một lần (SSO) trên các bên bị hạn chế (RP) đó trong cùng RWS với IdP. Tuy nhiên, RWS chỉ hỗ trợ quyền truy cập cookie trên nhiều trang web trên một số miền nhất định.
  • Sử dụng API xác thực web: API xác thực web cho phép các bên phụ thuộc (RP) đăng ký một nhóm các nguồn gốc có liên quan mà thông tin xác thực 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á tính năng Quản lý thông tin xác thực liên kết (FedCM): FedCM cho phép nhà cung cấp danh tính dựa vào Chrome để xử lý các luồng liên quan đến danh tính mà không cần 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 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ừ các phần nhúng

Giả sử 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 của 3-party-app.example hoặc thông qua 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 đặ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 được phân vùng và không thể truy cập vào cookie được đặt trong ngữ cảnh của bên thứ nhất trên 3-party-app.example.

Hình minh hoạ quy trình xác thực bằng cửa sổ bật lên giữa trang web RP và IdP bên thứ ba khi cookie của bên thứ ba bị hạn chế.
Quy trình xác thực bằng cửa sổ bật lên: Khi cookie của bên thứ ba bị hạn chế, iframe IdP của bên thứ ba được nhúng trên RP không thể truy cập vào cookie của chính nó.

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 và quay lại. Cookie được viết 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.

Hình minh hoạ quy trình xác thực bằng lệnh chuyển hướng giữa một trang web của bên bị hạn chế (RP) và một IdP bên thứ ba khi cookie của bên thứ ba bị hạn chế.
Luồng xác thực có lệnh chuyển hướng: Khi cookie của bên thứ ba bị hạn chế, cookie sẽ được ghi trong ngữ cảnh miền cấp cao nhất và không thể truy cập được trong iframe.

Trong trường hợp người dùng đã truy cập vào nguồn gốc được nhúng trong ngữ cảnh cấp cao nhất, API Truy cập bộ nhớ là một giải pháp phù hợp.

Để ngừng sử dụng các giải pháp dựa vào cookie của bên thứ ba, các nhà cung cấp danh tính nên áp dụng API FedCM và FedCM nên được gọi từ các lượt nhúng bên trong thay vì cửa sổ bật lên.

Một giải pháp đề xuất khác cho quy trình này, Popins được phân vùng, đang trong quá trình triển khai.

Đăng nhập bằng 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Đă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 (đăng nhập bằng Google) không còn đượ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 hơn đã loại bỏ việc phụ thuộc vào cookie của bên thứ ba, vì thư viện sẽ di chuyển thầm sang sử dụng FedCM để tương thích. Bạn nên kiểm thử trang web của mình bằng cách bật cờ kiểm thử giai đoạn loại bỏ cookie của bên thứ ba và sử dụng danh sách kiểm tra di chuyển FedCM để chuẩn bị (nếu cần).

Truy cập và sửa đổi dữ liệu người dùng từ các nội dung nhúng

Nội dung 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ý 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, trong đó 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 mình, 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 tiện ích đó 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ớiwebsite.example, CHIPS có thể giúp đảm bảo rằng 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 thuê bao 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 từ streaming.example được nhúng trên website.example và người dùng có gói thuê bao streaming.example cao cấp. Tiện ích này cần biết về gói thuê bao đó để tắt quảng cáo. Nếu cần truy cập cùng một cookie trên nhiều trang web, hãy cân nhắc sử dụng API Truy cập bộ nhớ nếu trước đó người dùng đã truy cập streaming.example ở cấp cao nhất và Bộ trang web có liên quan nếu nhóm website.example sở hữu streaming.example.

Kể từ Chrome 131, FedCM được tích hợp với API truy cập bộ nhớ. Với tính năng 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 quyền truy cập vào bộ nhớ chưa phân vùng.

Để biết thêm thông tin về việc chọn API nào để xử lý một hành trình cụ thể của người dùng với nội dung được nhúng, hãy xem Hướng dẫn về video nhúng.

Đăng xuất ở kênh chính

Đăng xuất qua kênh trước là một cơ chế cho phép người dùng đăng xuất khỏi tất cả ứng dụng có liên quan khi người dùng đăng xuất trên một dịch vụ. Tính năng đăng xuất qua kênh trước của OIDC yêu cầu IdP nhúng một số iframe của bên phụ thuộc (RP) dựa trên cookie của RP.

Nếu giải pháp của bạn dựa vào một nhà cung cấp danh tính, thì bạn có thể 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 hướng dẫn thêm, hãy liên hệ với nhà cung cấp danh tính của bạn.

Để giải quyết trường hợp sử dụng này, FedCM đã thử nghiệm với tính năng logoutRPs. Điều này cho phép IdP đăng xuất khỏi mọi RP mà người dùng đã phê duyệt trước đó cho hoạt động giao tiếp giữa RP-IdP. Tính năng này không còn được cung cấp nữa. Tuy nhiên, bạn nên xem đề xuất ban đầu và chia sẻ ý kiến phản hồi với chúng tôi nếu bạn quan tâm hoặc cần tính năng này.

Hành trình khác của người dùng

Hành trình của người dùng không dựa vào cookie của bên thứ ba sẽ không bị ảnh hưởng bởi những thay đổi trong 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 ngữ cảnh của bên thứ nhất, 2FA, sẽ hoạt động như dự kiến. Chúng tôi đã mô tả các điểm có thể bị vỡ 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. Báo cáo mọi sự cố gặp phải theo đường liên kết goo.gle/report-3pc-broken. Bạn cũng có thể gửi biểu mẫu phản hồi hoặc báo cáo vấn đề trên GitHub trong kho lưu trữ hỗ trợ nhà phát triển về Hộp cát về quyền riêng tư.

Kiểm tra trang web của bạn

Nếu trang web triển khai một trong các hành trình của người dùng theo mô tả trong hướng dẫn này, thì bạn cần đảm bảo rằng trang web của bạn được chuẩn bị sẵn sàng: kiểm tra trang web của bạn để sử dụng cookie của bên thứ ba, kiểm tra để tìm lỗi và chuyển sang các giải pháp đề xuất.