Mengelola sesi IAP

Halaman ini menjelaskan cara Identity-Aware Proxy (IAP) menangani permintaan dengan sesi yang sudah tidak berlaku lagi dan cara memastikan bahwa permintaan aplikasi AJAX berhasil.

Alur sesi IAP

Saat menggunakan alur login IAP standar, pengguna akan menerima cookie sesi yang merujuk ke sesi login Google mereka. IAP menggunakan cookie ini untuk mengonfirmasi bahwa pengguna masih login. IAP mewajibkan pengguna untuk login sebelum mengakses aplikasi yang diamankan IAP.

Sesi IAP diperbarui secara berkala. Namun, jika pengguna menggunakan Akun Google untuk login, sesi IAP juga terikat dengan sesi login Google pengguna. Dalam kasus ini, IAP hanya akan mengharuskan pengguna untuk login lagi dalam salah satu situasi berikut:

  • Pengguna telah logout dari akunnya
  • Akun mereka ditangguhkan
  • Akun memerlukan pengaturan ulang kata sandi

Jika pengguna logout, IAP mendeteksi perubahan status Akun Google dalam beberapa menit. Setelah terdeteksi, IAP akan membatalkan sesi.

IAP memeriksa ulang otorisasi Identity and Access Management (IAM) untuk semua permintaan selama sesi yang valid. Update pada kebijakan akses IAM aplikasi yang diamankan mungkin memerlukan waktu beberapa menit untuk diterapkan.

Akhir sesi IAP

Untuk alur login yang menggunakan Akun Google, sesi IAP terikat dengan sesi login Google yang mendasarinya, dan hanya berakhir saat sesi tersebut berakhir, terlepas dari klaim exp di JWT yang dikirim di header otorisasi.

Untuk autentikasi terprogram, IAP mematuhi klaim exp di JWT yang dikirim dalam header Otorisasi.

Untuk alur login Identity Platform, sesi IAP tetap valid hingga satu jam setelah pengguna logout.

Respons sesi yang sudah berakhir

IAP menampilkan respons yang berbeda untuk sesi yang habis masa berlakunya berdasarkan jenis permintaan.

Permintaan non-AJAX

Untuk permintaan non-AJAX, pengguna akan dialihkan ke alur login untuk memuat ulang sesi. Jika pengguna masih login, pengalihan ini bersifat transparan.

Permintaan AJAX

Chrome dan browser lain menghentikan cookie pihak ketiga secara bertahap. Rekomendasi untuk membuat permintaan AJAX di halaman ini tidak akan berfungsi jika cookie pihak ketiga dinonaktifkan. Namun, rekomendasi yang diberikan akan tetap berfungsi jika sumber dan target permintaan AJAX berasal dari situs yang sama.

Untuk mendapatkan petunjuk tentang cara mengelola cookie pihak ketiga di Chrome, lihat Menghapus, mengizinkan, dan mengelola cookie di Chrome.

IAP mengandalkan cookie untuk mengelola sesi pengguna. Proses ini juga bergantung pada urutan pengalihan untuk membangun sesi sebagai bagian dari alur login. Pembuatan sesi tidak selalu dapat dilakukan jika aplikasi menggunakan Cross-Origin Resource Sharing (CORS) untuk membuat permintaan AJAX ke aplikasi yang dilindungi IAP.

Agar berhasil membuat permintaan CORS ke aplikasi yang dilindungi IAP, sesi IAP harus dibuat out-of-band. Perlu diperhatikan bahwa untuk permintaan AJAX yang mengirimkan permintaan CORS dari source_domain->target_domain tempat target_domain menghosting aplikasi yang dilindungi IAP, perlu ada sesi yang dibuat di target_domain. Tidak ada cara untuk membagikan cookie antara source_domain dan target_domain.

Setelah sesi di target_domain dibuat, developer harus mengaktifkan kredensial agar dapat dikirim dalam permintaan. Secara default, metode JavaScript tidak melampirkan cookie ke permintaan. Untuk mengaktifkan kredensial dalam permintaan, permintaan yang dikirim dengan objek XMLHttpRequest harus menyetel properti withCredentials ke benar (true), sedangkan permintaan yang dikirim dengan Fetch API memerlukan opsi credentials yang disetel ke include atau same-origin.

Panduan berikut merekomendasikan pola bagi developer web agar dapat membuat dan memuat ulang sesi IAP.

Memahami respons IAP

Untuk permintaan AJAX, IAP menampilkan kode status HTTP 401: Unauthorized. Perhatikan bahwa deteksi permintaan AJAX tidak dapat dilakukan dengan sempurna. Jika Anda mendapatkan respons kode status 302, bukan kode status 401, untuk permintaan AJAX, header X-Requested-With dengan nilai "XMLHttpRequest" dapat ditambahkan ke permintaan AJAX. Tanda ini memberi tahu IAP bahwa permintaan berasal dari JavaScript.

Menangani respons AJAX HTTP 401

Untuk membuat sesi IAP setelah aplikasi menerima 401 HTTP, aplikasi dapat membuka jendela baru untuk URL target_domain + ?gcp-iap-mode=DO_SESSION_REFRESH. Ini adalah pengendali khusus yang hanya menetapkan sesi IAP di target_domain. Jika jendela dipertahankan sebagai terbuka, jendela akan terus memuat ulang sesi secara berkala, untuk meminta input pengguna sesuai kebutuhan. Secara opsional, pengguna dapat memilih untuk menutup jendela, dan pengendali untuk status 401 HTTP dalam kode developer akan memunculkan jendela lagi untuk refresh sesi sesuai kebutuhan.

Langkah 1: Ubah kode aplikasi

Contoh berikut menunjukkan cara memodifikasi kode aplikasi untuk menangani kode status HTTP 401 dan memberikan link pembaruan sesi kepada pengguna:

if (response.status === 401) {
  statusElm.innerHTML = 'Login stale. <input type="button" value="Refresh" onclick="sessionRefreshClicked();"/>';
}
Langkah 2: Instal pengendali onclick

Kode contoh di bawah ini menginstal pengendali GPC yang menutup jendela setelah sesi dimuat ulang:

var iapSessionRefreshWindow = null;

function sessionRefreshClicked() {
  if (iapSessionRefreshWindow == null) {
    iapSessionRefreshWindow = window.open("/?gcp-iap-mode=DO_SESSION_REFRESH");
    window.setTimeout(checkSessionRefresh, 500);
  }
  return false;
}

function checkSessionRefresh() {
  if (iapSessionRefreshWindow != null && !iapSessionRefreshWindow.closed) {
    fetch('/favicon.ico').then(function(response) {
      if (response.status === 401) {
        window.setTimeout(checkSessionRefresh, 500);
      } else {
        iapSessionRefreshWindow.close();
        iapSessionRefreshWindow = null;
      }
    });
  } else {
    iapSessionRefreshWindow = null;
  }
}