Chrome mengusulkan pengalaman baru untuk pilihan pengguna dengan cookie pihak ketiga. Anda perlu menyiapkan situs untuk pengguna yang memilih menjelajah tanpa cookie pihak ketiga.
Di halaman ini, Anda akan menemukan informasi tentang skenario identitas yang kemungkinan besar akan terpengaruh, serta referensi ke kemungkinan solusi.
Jika situs Anda hanya menangani alur dalam domain dan subdomain yang sama, seperti
publisher.example dan login.publisher.example, situs tersebut tidak akan menggunakan cookie lintas situs
dan alur login Anda tidak akan terpengaruh oleh perubahan cookie pihak ketiga.
Namun, jika situs Anda menggunakan domain terpisah untuk login, seperti dengan Login dengan Google atau Login dengan Facebook, atau situs Anda perlu berbagi autentikasi pengguna di beberapa domain atau subdomain, ada kemungkinan Anda perlu melakukan perubahan pada situs untuk memastikan transisi yang lancar dari cookie lintas situs.
Perjalanan umum pengguna
Secara historis, banyak alur kerja identitas mengandalkan cookie pihak ketiga. Tabel ini mencantumkan beberapa perjalanan pengguna umum dan potensi solusi untuk setiap perjalanan yang tidak bergantung pada cookie pihak ketiga. Bagian berikut akan menjelaskan alasan rekomendasi ini.
API alternatif yang direkomendasikan untuk kasus penggunaan umum
| Perjalanan pengguna | API yang Direkomendasikan |
|---|---|
| Login dengan akun media sosial |
Untuk penyedia identitas: terapkan FedCM Untuk pihak tepercaya: hubungi penyedia identitas Anda |
| Logout Channel Depan | Untuk penyedia identitas: terapkan FedCM |
|
Untuk penyedia identitas atau solusi kustom: Set Situs Terkait |
|
| Pengelolaan profil pengguna |
Storage Access API Related Website Sets CHIPS FedCM + SAA |
|
Storage Access API Related Website Sets CHIPS FedCM + SAA |
|
| Autentikasi |
Storage Access API FedCM Web Authentication API sciencePopin yang Dipartisi |
| Skenario ini umumnya tidak memiliki dependensi cookie pihak ketiga dan diperkirakan tidak akan terpengaruh. |
Menguji perjalanan pengguna terkait identitas
Cara terbaik untuk menguji apakah alur login Anda terpengaruh oleh perubahan cookie pihak ketiga adalah dengan melakukan pendaftaran, pemulihan sandi, alur login, dan logout dengan tanda pengujian cookie pihak ketiga diaktifkan.
Berikut adalah checklist hal-hal yang perlu diperiksa setelah Anda membatasi cookie pihak ketiga:
- Pendaftaran pengguna: Membuat akun baru berfungsi seperti yang diharapkan. Jika menggunakan penyedia identitas pihak ketiga, pastikan pendaftaran akun baru berfungsi untuk setiap integrasi.
- Pemulihan sandi: Pemulihan sandi berfungsi seperti yang diharapkan, mulai dari UI web, hingga CAPTCHA, hingga menerima email pemulihan sandi.
- Login: Alur kerja login berfungsi dalam domain yang sama dan saat membuka domain lain. Jangan lupa untuk menguji setiap integrasi login.
- Logout: Proses logout berfungsi seperti yang diharapkan, dan pengguna tetap logout setelah alur logout.
Anda juga harus menguji apakah fitur situs lain yang memerlukan login pengguna tetap berfungsi tanpa cookie lintas situs, terutama jika fitur tersebut melibatkan pemuatan resource lintas situs. Misalnya, jika Anda menggunakan CDN untuk memuat gambar profil pengguna, pastikan CDN tersebut masih berfungsi. Jika Anda memiliki perjalanan penting pengguna, seperti checkout, yang dibatasi pada login, pastikan perjalanan tersebut terus berfungsi.
Solusi login
Di bagian ini, Anda akan menemukan informasi yang lebih spesifik tentang pengaruh perubahan tersebut terhadap alur tersebut.
Single Sign-On (SSO) pihak ketiga
Single sign-on (SSO) pihak ketiga memungkinkan pengguna melakukan autentikasi dengan satu set kredensial di satu platform, lalu mengakses beberapa aplikasi dan situs tanpa harus memasukkan ulang informasi login mereka. Karena kompleksitas penerapan solusi SSO, banyak perusahaan memilih untuk menggunakan penyedia solusi pihak ketiga, untuk membagikan status login di antara beberapa origin. Contoh penyedia meliputi Okta, Ping Identity, Google Cloud IAM, atau Microsoft Entra ID.
Jika solusi Anda mengandalkan penyedia pihak ketiga, mungkin diperlukan beberapa perubahan kecil, seperti upgrade library. Pendekatan terbaiknya adalah dengan meminta panduan dari penyedia tentang pengaruh dependensi cookie pihak ketiga terhadap solusi dan pendekatan yang mereka rekomendasikan untuk layanan mereka. Beberapa penyedia akan bermigrasi secara diam-diam dari cookie pihak ketiga, sehingga pihak tepercaya tidak perlu melakukan update.
Beberapa domain
Beberapa situs menggunakan domain yang berbeda hanya untuk mengautentikasi pengguna yang tidak memenuhi syarat untuk cookie situs yang sama, seperti situs yang menggunakan example.com untuk situs utama dan login.example untuk alur login, yang mungkin memerlukan akses ke cookie pihak ketiga untuk memastikan bahwa pengguna diautentikasi di kedua domain.
Beberapa bisnis dapat memiliki beberapa produk yang dihosting di domain atau subdomain yang berbeda. Solusi tersebut mungkin ingin membagikan sesi pengguna di seluruh produk tersebut, sebuah skenario yang mungkin memerlukan akses ke cookie pihak ketiga di antara beberapa domain.
Kemungkinan jalur migrasi untuk skenario ini adalah:
- Memperbarui untuk menggunakan cookie pihak pertama ("situs yang sama"): Mengubah infrastruktur situs sehingga alur login dihosting di domain yang sama (atau subdomain) dengan situs utama, yang hanya akan menggunakan cookie pihak pertama. Hal ini mungkin memerlukan upaya yang lebih tinggi, bergantung pada cara infrastruktur disiapkan.
- Gunakan Related Website Sets (RWS) dan Storage Access API (SAA): RWS memungkinkan akses cookie lintas situs terbatas antara sekelompok kecil domain terkait. Dengan RWS, tidak ada perintah pengguna yang diperlukan saat meminta akses penyimpanan dengan Storage Access API. Hal ini memungkinkan SSO di RP yang berada di RWS yang sama dengan IdP. Namun, RWS hanya mendukung akses cookie lintas situs di sejumlah domain tertentu.
- Gunakan Web Authentication API: Web Authentication API memungkinkan pihak tepercaya (RP) mendaftarkan kumpulan asal terkait yang terbatas tempat kredensial dapat dibuat dan digunakan.
- Jika Anda mengautentikasi pengguna di lebih dari 5 domain terkait, jelajahi Federated Credentials Management (FedCM): FedCM memungkinkan penyedia identitas mengandalkan Chrome untuk menangani alur terkait identitas tanpa memerlukan cookie pihak ketiga. Dalam kasus Anda, "domain login" dapat bertindak sebagai penyedia identitas FedCM dan digunakan untuk mengautentikasi pengguna di seluruh domain Anda yang lain.
Autentikasi dari penyematan
Misalkan iframe 3-party-app.example disematkan di top-level.example. Di 3-party-app.example, pengguna dapat login dengan kredensial 3-party-app.example, atau dengan penyedia pihak ketiga lainnya.
Pengguna mengklik "login", dan melakukan autentikasi dalam pop-up 3-party-app.example. Pop-up 3-party-app.example menetapkan cookie pihak pertama. Namun, iframe 3-party-app.example yang disematkan di top-level.example dipartisi dan tidak dapat mengakses cookie yang ditetapkan dalam konteks pihak pertama di 3-party-app.example.
Masalah yang sama akan terjadi saat pengguna dialihkan dari top-level.example ke 3-party-app.example dan kembali. Cookie ditulis dalam konteks pihak pertama situs 3-party-app.example, tetapi dipartisi dan tidak dapat diakses dalam iframe 3-party-app.example.
Jika pengguna telah mengunjungi origin tersemat dalam konteks tingkat atas, Storage Access API adalah solusi yang baik.
Untuk bermigrasi dari solusi yang mengandalkan cookie pihak ketiga, sebaiknya penyedia identitas mengadopsi FedCM API dan FedCM dipanggil dari dalam penyematan, bukan pop-up.
Solusi lain yang diusulkan untuk alur ini, Popin yang Dipartisi, sedang dalam penerapan.
Login dengan Akun Media Sosial
Tombol login seperti Login dengan Google, Login dengan Facebook, dan Login dengan Twitter adalah tanda pasti bahwa situs Anda menggunakan penyedia identitas gabungan. Setiap penyedia identitas gabungan akan memiliki penerapannya sendiri.
Jika menggunakan library platform JavaScript Google Login yang tidak digunakan lagi, Anda dapat menemukan informasi tentang cara bermigrasi ke library Google Identity Services yang lebih baru untuk autentikasi dan otorisasi.
Sebagian besar situs yang menggunakan library Google Identity Services yang lebih baru telah menghapus ketergantungan pada cookie pihak ketiga, karena library akan dimigrasikan secara otomatis untuk menggunakan FedCM demi kompatibilitas. Sebaiknya uji situs Anda dengan tanda pengujian penghentian penggunaan cookie pihak ketiga diaktifkan dan, jika diperlukan, gunakan checklist migrasi FedCM untuk melakukan persiapan.
Mengakses dan mengubah data pengguna dari penyematan
Konten tersemat sering digunakan untuk perjalanan pengguna seperti mengakses atau mengelola data profil atau langganan pengguna.
Misalnya, pengguna mungkin login ke website.example, yang menyematkan widget subscriptions.example. Widget ini memungkinkan pengguna mengelola data mereka, seperti berlangganan konten premium atau memperbarui informasi penagihan. Untuk mengubah data pengguna, widget sematan mungkin perlu mengakses cookie-nya sendiri saat disematkan di website.example. Dalam skenario saat data ini harus diisolasi kewebsite.example, CHIPS dapat membantu memastikan bahwa penyematan dapat mengakses informasi yang diperlukan. Dengan CHIPS, widget subscriptions.example yang disematkan di website.example tidak akan memiliki akses ke data langganan pengguna di situs lain.
Pertimbangkan kasus lain: video dari streaming.example disematkan di website.example, dan pengguna memiliki langganan streaming.example premium, yang perlu diketahui widget untuk menonaktifkan iklan. Jika cookie yang sama perlu diakses di beberapa situs, pertimbangkan untuk menggunakan Storage Access API jika pengguna sebelumnya telah mengunjungi streaming.example sebagai tingkat teratas, dan Related Website Sets jika kumpulan website.example memiliki streaming.example.
Mulai Chrome 131, FedCM terintegrasi dengan Storage Access API. Dengan integrasi ini, saat pengguna menerima perintah FedCM, browser akan memberikan akses penyematan IdP ke penyimpanan yang tidak dipartisi.
Untuk informasi selengkapnya tentang API mana yang harus dipilih untuk menangani perjalanan pengguna tertentu dengan konten tersemat, lihat Panduan penyematan.
Logout saluran depan
Logout saluran depan adalah mekanisme yang memungkinkan pengguna logout dari semua aplikasi terkait saat pengguna logout di satu layanan. Logout saluran depan OIDC mengharuskan IdP menyematkan beberapa iframe pihak tepercaya (RP) yang mengandalkan cookie RP.
Jika solusi Anda mengandalkan penyedia identitas, perubahan kecil (seperti upgrade library) mungkin diperlukan. Untuk mendapatkan panduan lebih lanjut, hubungi penyedia identitas Anda.
Untuk mengatasi kasus penggunaan ini, FedCM bereksperimen dengan fitur logoutRPs. Hal ini memungkinkan IdP logout dari RP mana pun yang sebelumnya telah disetujui pengguna untuk komunikasi RP-IdP. Fitur ini tidak lagi tersedia, tetapi sebaiknya Anda melihat proposal awal dan memberikan masukan kepada kami jika Anda tertarik atau memerlukan fitur ini.
Perjalanan pengguna lainnya
Perjalanan pengguna yang tidak mengandalkan cookie pihak ketiga seharusnya tidak terpengaruh oleh perubahan pada cara Chrome menangani cookie pihak ketiga. Solusi yang ada, seperti login, logout, atau pemulihan akun dalam konteks pihak pertama, 2FA, akan berfungsi sebagaimana mestinya. Potensi titik kerusakan telah dijelaskan sebelumnya. Untuk informasi selengkapnya tentang API tertentu, lihat halaman status API. Laporkan setiap gangguan yang dialami ke goo.gle/report-3pc-broken. Anda juga dapat mengirimkan formulir masukan atau melaporkan masalah di GitHub di repositori dukungan developer Privacy Sandbox.
Mengaudit situs
Jika situs Anda menerapkan salah satu perjalanan pengguna yang dijelaskan dalam panduan ini, Anda perlu memastikan situs Anda siap: audit situs Anda untuk mengetahui penggunaan cookie pihak ketiga, uji kerusakan, dan beralih ke solusi yang direkomendasikan.