Memeriksa dampak perubahan cookie pihak ketiga terhadap alur kerja login

Cookie pihak ketiga dapat diblokir oleh pembatasan browser, setelan pengguna, flag developer, atau kebijakan perusahaan.

Anda harus memastikan situs atau layanan Anda memberikan pengalaman yang baik bagi semua pengguna, terlepas dari tersedia atau tidaknya cookie pihak ketiga.

Di halaman ini, Anda akan menemukan informasi tentang skenario identitas yang paling mungkin 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 membagikan autentikasi pengguna di beberapa domain atau subdomain, ada kemungkinan Anda perlu melakukan perubahan pada situs Anda untuk memastikan transisi yang lancar dari cookie lintas situs.

Perjalanan umum pengguna

Dulu, banyak alur kerja identitas mengandalkan cookie pihak ketiga. Tabel mencantumkan beberapa perjalanan pengguna umum dan potensi solusi untuk setiap perjalanan pengguna yang tidak bergantung pada cookie pihak ketiga. Bagian berikut akan menjelaskan alasan rekomendasi ini.

dalam tabel masih dalam tahap awal pengembangan. Masukan Anda sangat berharga dan akan membantu membentuk masa depan mereka. Sampaikan pendapat Anda tentang API ini: Popin yang Dipartisi.

Perjalanan pengguna API yang direkomendasikan
Login dengan akun media sosial Untuk penyedia identitas: terapkan FedCM
Untuk pihak tepercaya: hubungi penyedia identitas Anda

Single sign-on

Untuk penyedia identitas atau solusi kustom: Set Situs Terkait

Pengelolaan profil pengguna Storage Access API
Kumpulan Situs Terkait
CHIPS
FedCM + SAA

Pengelolaan langganan

 Storage Access API
Kumpulan Situs Terkait
CHIPS
FedCM + SAA
Autentikasi Storage Access API
FedCM
Web Authentication API
Partitioned Popins

Perjalanan pengguna lainnya

 Umumnya, skenario ini tidak memiliki dependensi cookie pihak ketiga dan diperkirakan tidak akan terpengaruh.

Cara terbaik untuk menguji apakah alur login Anda terpengaruh oleh perubahan cookie pihak ketiga adalah dengan menjalankan alur pendaftaran, pemulihan sandi, login, dan logout dengan flag pengujian cookie pihak ketiga diaktifkan.

Berikut checklist hal-hal yang perlu diperiksa setelah Anda membatasi cookie pihak ketiga:

  • Pendaftaran pengguna: Pembuatan akun baru berfungsi seperti yang diharapkan. Jika menggunakan penyedia identitas pihak ketiga, periksa apakah 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 beralih ke 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 bahwa 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 hal ini tetap berfungsi. Jika Anda memiliki perjalanan pengguna yang penting, seperti checkout, yang dibatasi oleh login, pastikan perjalanan pengguna ini terus berfungsi.

Solusi login

Di bagian ini, Anda akan menemukan informasi yang lebih spesifik tentang cara alur tersebut mungkin terpengaruh.

Single Sign-On (SSO) Pihak Ketiga

Login tunggal (SSO) pihak ketiga memungkinkan pengguna melakukan autentikasi dengan satu set kredensial di satu platform, lalu mengakses beberapa aplikasi dan situs tanpa harus memasukkan kembali 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, beberapa perubahan kecil, seperti upgrade library, mungkin diperlukan. Cara terbaik adalah dengan meminta panduan dari penyedia tentang pengaruh dependensi cookie pihak ketiga terhadap solusi dan pendekatan yang direkomendasikan untuk layanan mereka. Beberapa penyedia akan melakukan migrasi 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 same-site, 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 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:

  • Perubahan 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 besar, bergantung pada cara penyiapan infrastruktur.
  • Menggunakan Set Situs Terkait (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 kecil domain.
  • Menggunakan Web Authentication API: Web Authentication API memungkinkan pihak tepercaya (RP) mendaftarkan sekumpulan kecil asal terkait yang dapat digunakan untuk membuat dan menggunakan kredensial.
  • Jika Anda mengautentikasi pengguna di lebih dari 5 domain terkait, pelajari 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" Anda dapat bertindak sebagai penyedia identitas FedCM dan digunakan untuk mengautentikasi pengguna di seluruh domain Anda yang lain.

Autentikasi dari sematan

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.

Ilustrasi alur autentikasi dengan pop-up antara situs RP dan IdP pihak ketiga saat cookie pihak ketiga dibatasi.
Alur autentikasi dengan pop-up: Jika cookie pihak ketiga dibatasi, iframe IdP pihak ketiga yang disematkan di RP tidak dapat mengakses cookie-nya sendiri.

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.

Ilustrasi alur autentikasi dengan pengalihan antara situs RP dan IdP pihak ketiga saat cookie pihak ketiga dibatasi.
Alur autentikasi dengan pengalihan: Jika cookie pihak ketiga dibatasi, cookie akan ditulis dalam konteks domain tingkat teratas dan tidak dapat diakses dalam iframe.

Jika pengguna telah mengunjungi origin sematan dalam konteks tingkat teratas, Storage Access API adalah solusi yang baik.

Untuk bermigrasi dari solusi yang mengandalkan cookie pihak ketiga, sebaiknya penyedia identitas menggunakan FedCM API dan FedCM dipanggil dari dalam sematan, bukan pop-up.

Solusi lain yang diusulkan untuk alur ini, Popin yang Dipartisi, sedang dalam tahap 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 implementasinya sendiri.

Jika Anda menggunakan library platform Google Sign-In JavaScript 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 bermigrasi secara diam-diam untuk menggunakan FedCM demi kompatibilitas. Sebaiknya uji situs Anda dengan mengaktifkan tanda pengujian penghapusan cookie pihak ketiga dan, jika diperlukan, gunakan checklist migrasi FedCM untuk bersiap.

Mengakses dan mengubah data pengguna dari sematan

Konten sematan sering digunakan untuk perjalanan pengguna seperti mengakses atau mengelola data profil atau langganan pengguna.

Misalnya, pengguna dapat 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 sematan dapat mengakses informasi yang dibutuhkannya. Dengan CHIPS, subscriptions.examplewidget 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 premium streaming.example, yang harus diketahui widget untuk menonaktifkan iklan. Jika cookie yang sama perlu diakses di beberapa situs, pertimbangkan untuk menggunakan Storage Access API jika pengguna telah mengunjungi streaming.example sebagai tingkat teratas sebelumnya, dan Set Situs Terkait jika set website.example memiliki streaming.example.

Mulai Chrome 131, FedCM diintegrasikan dengan Storage Access API. Dengan integrasi ini, saat pengguna menerima perintah FedCM, browser akan memberikan akses sematan IdP ke penyimpanan yang tidak dipartisi.

Untuk mengetahui informasi selengkapnya tentang API yang harus dipilih untuk menangani perjalanan pengguna tertentu dengan konten sematan, lihat Panduan sematan.

Perjalanan pengguna lainnya

Perjalanan pengguna yang tidak bergantung pada cookie pihak ketiga tidak akan terpengaruh oleh perubahan cara Chrome menangani cookie pihak ketiga. Solusi yang ada, seperti login, logout, atau pemulihan akun dalam konteks pihak pertama, 2FA, harus berfungsi sebagaimana mestinya. Potensi titik kerusakan telah dijelaskan sebelumnya. Untuk mengetahui informasi selengkapnya tentang API tertentu, periksa halaman status API.

Mengaudit situs Anda

Jika situs Anda menerapkan salah satu perjalanan pengguna yang dijelaskan dalam panduan ini, Anda harus memastikan situs Anda siap: audit situs Anda untuk mengetahui penggunaan cookie pihak ketiga, uji apakah ada kerusakan, dan beralih ke solusi yang direkomendasikan.