Cara menangani pemblokiran cookie pihak ketiga di browser

Banyak browser memblokir cookie pihak ketiga, cookie pada permintaan ke domain selain domain yang ditampilkan di bilah alamat browser. Cookie ini juga dikenal sebagai cookie lintas domain. Blok ini memutus alur implisit dan memerlukan pola autentikasi baru agar pengguna berhasil masuk. Dalam platform identitas Microsoft, kami menggunakan alur otorisasi dengan Proof Key for Code Exchange (PKCE) dan token refresh untuk membuat pengguna tetap masuk ketika cookie pihak ketiga diblokir. Alur kode otorisasi dengan pendekatan Proof Key for Code Exchange ini direkomendasikan melalui alur implisit.

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

Apple Safari memiliki fitur perlindungan privasi on-by-default yang disebut 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 internet. Sayangnya, pola ini juga merupakan cara standar untuk mengimplementasikan alur implisit di aplikasi satu halaman (SPAs). Browser yang memblokir cookie pihak ketiga untuk melindungi privasi pengguna juga dapat memblokir fungsionalitas SPA. Penggunaan alur implisit dalam SPAs tidak lagi direkomendasikan karena pemblokiran cookie pihak ketiga dan risiko keamanan yang terkait dengannya.

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 autentikasi, idP mengeluarkan kode, dan SPA menukarkan 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 jenis spa untuk mengaktifkan CORS pada titik akhir masuk.
• Token refresh yang dikeluarkan melalui alur kode otorisasi untuk spa mengalihkan URI memiliki masa pakai 24 jam daripada masa pakai 90 hari.

Implikasi performa dan UX

Beberapa aplikasi yang menggunakan upaya alur implisit masuk 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 memasukkan pengguna, 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 SPAs sehingga aplikasi tidak diunduh secara penuh dua kali.
  • Pertimbangkan untuk memiliki urutan pra-muat di aplikasi yang memeriksa sesi masuk dan mengalihkan ke halaman login sebelum aplikasi sepenuhnya membongkar dan menjalankan payload JavaScript.
• Popup
  • Jika pengalaman pengguna (UX) pengalihan halaman lengkap 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 memberikan 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 autentikasi 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 iframed dan induk dengan akses API skrip JavaScript asal dan lintas asal dengan meneruskan petunjuk pengguna (akun) dari aplikasi induk ke aplikasi iframed. Untuk informasi selengkapnya, lihat Menggunakan MSAL.js di aplikasi iframed di repositori MSAL.js di GitHub.

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 login.

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 keamanan OAuth saat ini) menjadi onerous ketika token baru atau tambahan diperlukan. Pengalihan halaman penuh atau popup diperlukan untuk setiap token tunggal, setiap kali token kedaluwarsa (setiap jam biasanya, 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 (seperti login.contoso.com 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.
• MSAL.js mulai cepat 2.0.