Cara menangani pemblokiran cookie pihak ketiga di browser

Banyak browser memblokir cookie pihak ketiga, cookie berdasarkan permintaan ke domain selain domain yang ditampilkan di bilah alamat browser. Cookie ini juga dikenal sebagai cookie lintas domain. Hal ini memutus alur implisit dan memerlukan pola autentikasi baru agar berhasil memasukkan pengguna. Di platform identitas Microsoft, kami menggunakan alur otorisasi dengan Proof Key for Code Exchange (PKCE) dan refresh token untuk memastikan pengguna tetap masuk saat cookie pihak ketiga diblokir.

Apa itu Intelligent Tracking Protection (ITP) dan Privacy Sandbox?

Apple Safari memiliki fitur perlindungan privasi yang secara default aktif bernama Intelligent Tracking Protection atau ITP. Chrome memiliki inisiatif privasi browser bernama Privacy Sandbox. Inisiatif ini mencakup banyak upaya privasi browser yang berbeda oleh browser dan memiliki garis waktu yang berbeda. Kedua upaya memblokir cookie "pihak ketiga" atas permintaan yang melintasi domain, dengan Safari dan Brave memblokir cookie pihak ketiga secara default. Chrome baru-baru ini mengumumkan bahwa mereka akan mulai memblokir cookie pihak ketiga secara default. Kotak Pasir Privasi mencakup perubahan pada penyimpanan yang dipartisi serta pemblokiran cookie pihak ketiga.

Bentuk umum pelacakan pengguna dilakukan dengan memuat iframe ke situs pihak ketiga di latar belakang dan menggunakan cookie untuk menghubungkan pengguna di seluruh Internet. Sayangnya, pola ini juga merupakan cara standar untuk menerapkan alur implisit dalam aplikasi halaman tunggal (SPAs). Browser yang memblokir cookie pihak ketiga untuk melindungi privasi pengguna juga dapat memblokir fungsionalitas SPA.

Solusi yang diuraikan dalam artikel ini berfungsi di semua browser ini, atau di mana saja cookie pihak ketiga diblokir.

Gambaran umum solusi

Untuk terus mengautentikasi pengguna di SPAs, pengembang aplikasi harus menggunakan alur kode otorisasi. Dalam alur kode auth, penyedia identitas mengeluarkan kode, dan SPA menukar kode untuk token akses dan token refresh. Saat aplikasi memerlukan token baru, aplikasi dapat menggunakan alur token refresh untuk mendapatkan token baru. Microsoft Authentication Library (MSAL) untuk JavaScript v2.0 dan yang lebih tinggi, mengimplementasikan alur kode otorisasi untuk SPAs dan, dengan pembaruan kecil, adalah pengganti drop-in untuk MSAL.js 1.x. Lihat panduan migrasi untuk memindahkan SPA dari alur kode implisit ke autentikasi.

Untuk platform identitas Microsoft, SPAs dan klien asli mengikuti panduan protokol serupa:

• Penggunaan tantangan kode PKCE
  • PKCE diperlukan untuk SPAs pada platform identitas Microsoft. PKCE direkomendasikan untuk klien asli dan rahasia.
• Tidak ada penggunaan rahasia klien

SPAs memiliki dua batasan lagi:

• URI pengalihan harus ditandai sebagai jenisspauntuk mengaktifkan CORS pada titik akhir log masuk.
• Token refresh yang dikeluarkan melalui alur kode otorisasi ke spa URI pengalihan memiliki masa pakai 24 jam daripada masa pakai 90 hari.

Implikasi kinerja dan UX

Beberapa aplikasi menggunakan upaya masuk alur implisit tanpa mengalihkan dengan membuka iframe login menggunakan prompt=none. Di sebagian besar browser, permintaan ini merespons dengan token untuk pengguna yang saat ini masuk (dengan asumsi persetujuan diberikan). Pola ini berarti aplikasi tidak memerlukan pengalihan halaman penuh untuk mengizinkan pengguna masuk, meningkatkan performa dan pengalaman pengguna - pengguna mengunjungi halaman web dan sudah masuk. Karena prompt=none dalam iframe tidak lagi menjadi opsi ketika cookie pihak ketiga diblokir, aplikasi harus menyesuaikan pola masuk mereka agar kode otorisasi dikeluarkan.

Tanpa cookie pihak ketiga, ada dua cara untuk mencapai rincian masuk:

• Pengalihan halaman penuh
  • Pada beban pertama SPA, alihkan pengguna ke halaman masuk jika tidak ada sesi (atau jika sesi kedaluwarsa). Browser pengguna mengunjungi halaman masuk, menyajikan cookie yang berisi sesi pengguna, dan kemudian dialihkan kembali ke aplikasi dengan kode dan token dalam fragmen.
  • Pengalihan memang mengakibatkan SPA dimuat dua kali. Ikuti praktik terbaik untuk penembolokan SPA sehingga aplikasi tidak diunduh secara penuh dua kali.
  • Pertimbangkan untuk memiliki urutan pramuat di aplikasi yang memeriksa sesi log masuk dan mengalihkan ke halaman log masuk sebelum aplikasi sepenuhnya membongkar dan menjalankan payload JavaScript.
• Popup
  • Jika pengalaman pengguna (UX) terhadap pengalihan halaman penuh tidak berfungsi untuk aplikasi, pertimbangkan untuk menggunakan popup untuk menangani autentikasi.
  • Ketika popup selesai dialihkan ke aplikasi setelah autentikasi, kode di handler pengalihan akan menyimpan kode autentikasi, dan token di penyimpanan lokal untuk digunakan aplikasi. MSAL.js mendukung popup untuk autentikasi, seperti halnya sebagian besar pustaka.
  • Browser mengurangi dukungan untuk popup, sehingga mungkin bukan opsi yang paling dapat diandalkan. Interaksi pengguna dengan SPA sebelum membuat popup mungkin diperlukan untuk memenuhi persyaratan browser.

Apple menjelaskan metode popup sebagai perbaikan kompatibilitas sementara untuk memberi akses jendela asli ke cookie pihak ketiga. Meskipun Apple dapat menghapus transfer izin ini di masa mendatang, itu tidak akan berdampak pada panduan di sini.

Di sini, popup digunakan sebagai navigasi pihak pertama ke halaman login sehingga sesi ditemukan dan kode auth dapat disediakan. Ini harus terus bekerja ke masa depan.

Pengembang dapat terus menggunakan prompt=none dengan harapan bahwa mereka melihat tingkat kesalahan interacion_required yang lebih tinggi ketika cookie pihak ketiga diblokir. Rekomendasinya adalah untuk selalu memiliki fallback metode interaktif, jika kegagalan selama akuisisi token senyap terjadi.

Menggunakan iframe

Pola umum dalam aplikasi web adalah menggunakan iframe untuk menyematkan satu aplikasi di dalam aplikasi lain: bingkai tingkat atas menangani autentikasi pengguna dan aplikasi yang dihosting di iframe dapat mempercayai bahwa pengguna masuk, mengambil token secara diam-diam menggunakan alur implisit. Namun, ada beberapa peringatan untuk asumsi ini terlepas dari apakah cookie pihak ketiga diaktifkan atau diblokir di browser.

Akuisisi token senyap tidak lagi berfungsi ketika cookie pihak ketiga diblokir - aplikasi yang disematkan dalam iframe harus beralih menggunakan popup untuk mengakses sesi pengguna karena tidak dapat menavigasi ke halaman masuk dalam bingkai yang disematkan.

Anda dapat mencapai akses menyeluruh antara aplikasi iframe dan aplikasi induk dengan akses API skrip JavaScript asal yang sama dan lintas asal dengan meneruskan petunjuk pengguna (akun) dari aplikasi induk ke aplikasi iframe. Untuk informasi selengkapnya, lihat Menggunakan MSAL.js di aplikasi iframed di repositori MSAL.js di GitHub.

Pelajari lebih lanjut tentang implikasi keamanan token refresh di browser

Serangan skrip lintas situs (XSS) atau paket JS yang disusupi dapat mencuri token refresh dan menggunakannya dari jarak jauh sampai kedaluwarsa atau dicabut. Pengembang aplikasi bertanggung jawab untuk mengurangi risiko aplikasi mereka terhadap pembuatan skrip lintas situs. Untuk meminimalkan risiko token refresh yang dicuri, SPAs dikeluarkan token yang hanya berlaku selama 24 jam. Setelah 24 jam, aplikasi harus memperoleh kode otorisasi baru melalui kunjungan bingkai tingkat atas ke halaman log masuk.

Pola token refresh seumur hidup terbatas ini dipilih sebagai keseimbangan antara keamanan dan UX yang terdegradasi. Tanpa token refresh atau cookie pihak ketiga, alur kode otorisasi (seperti yang direkomendasikan oleh draf praktik terbaik saat ini keamanan OAuth)menjadi berat ketika token baru atau tambahan diperlukan. Pengalihan halaman penuh atau popup diperlukan untuk setiap token, setiap kali token kedaluwarsa (biasanya setiap jam, untuk token platform identitas Microsoft).

Mitigasi spesifik jenis pengguna

Tidak semua pengguna dan aplikasi dipengaruhi secara seragam oleh cookie pihak ketiga. Ada beberapa skenario di mana karena arsitektur atau manajemen perangkat, panggilan senyap untuk memperbarui token dapat dilakukan tanpa cookie pihak ketiga.

Untuk skenario perangkat perusahaan terkelola, kombinasi browser dan platform tertentu memiliki dukungan untuk Akses Bersyariah perangkat. Menerapkan identitas perangkat meminimalkan kebutuhan akan cookie pihak ketiga karena status autentikasi dapat berasal dari perangkat alih-alih browser.

Untuk skenario aplikasi Azure AD B2C, pelanggan dapat menyiapkan domain masuk kustom agar sesuai dengan domain aplikasi. Browser tidak akan memblokir cookie pihak ketiga dalam skenario ini karena cookie tetap berada di domain yang sama (misalnya login.contoso.com ke app.contoso.com).

Batasan pada Logout Saluran Depan tanpa cookie pihak ketiga

Saat mengeluarkan pengguna dari SPA, MSAL.js merekomendasikan penggunaan metode popup atau mengalihkan keluar. Meskipun ini menghapus sesi autentikasi di server dan di penyimpanan browser, ada risiko bahwa tanpa akses ke cookie pihak ketiga, tidak semua aplikasi federasi akan melihat keluar secara bersamaan. Ini adalah batasan yang diketahui dari spesifikasi OpenID Front-Channel Logout 1.0. Artinya bagi pengguna adalah bahwa token akses yang ada untuk aplikasi lain untuk pengguna yang sama akan terus berlaku sampai waktu kedaluwarsa mereka. Pengguna dapat keluar dari aplikasi A di tab A, tetapi aplikasi B di tab B masih akan muncul sebagai masuk untuk sisa waktu token akses yang valid. Ketika token aplikasi B kedaluwarsa dan panggilan dilakukan ke server untuk mendapatkan token baru, aplikasi B menerima respons dari server bahwa sesi kedaluwarsa dan meminta pengguna untuk mengautentikasi.

Halaman keluar Microsoft dan praktik terbaik privasi internet merekomendasikan agar pengguna menutup semua jendela browser setelah keluar dari aplikasi.

Langkah berikutnya

Untuk informasi selengkapnya tentang alur kode otorisasi dan MSAL.js, lihat:

• Alur kode otorisasi.
• Mulai cepat MSAL.js 2.0.