Petunjuk dan konteks
Sebuah klien SaaS terintegrasi dengan enterprise IdP, public IdP, dan authorization server mitra. Penyerang mencoba membuat klien memperlakukan permintaan yang dimulai pada server A sebagai respons dari server B, yang berpotensi mengirimkan authorization code ke token endpoint yang salah atau menerapkan konfigurasi klien yang salah. Rancang pertahanan Mix-Up yang mencakup issuer binding, authorization response, token exchange, penemuan metadata, penanganan kesalahan (error), dan migrasi.
RFC 9207 mendefinisikan parameter respons iss agar authorization server dapat mengidentifikasi dirinya sendiri dalam OAuth authorization response. RFC 9700 mencantumkan identifikasi issuer sebagai pertahanan terhadap Mix-Up. Tujuannya adalah untuk mengikat "pengguna yang kembali" dengan "authorization server mana yang menyelesaikan alur ini", daripada hanya mengandalkan state.
Hal yang diuji oleh pewawancara
- Pemahaman tentang kebingungan kode, token-endpoint, dan konfigurasi klien dalam alur multi-issuer.
- Pengikatan issuer ke state, redirect URI, PKCE, dan rekaman permintaan otorisasi.
- Pemeriksaan konsistensi pada metadata discovery, URL issuer, TLS, JWKS, dan token endpoint.
- Penanganan yang aman terhadap nilai
issyang hilang, tidak dikenal, berkonflik, atau dipalsukan. - Rencana migrasi yang mendukung IdP versi lama tanpa mempertahankan fallback yang tidak aman untuk selamanya.
Pertanyaan klarifikasi
- Apakah daftar issuer bersifat statis, terdaftar secara dinamis, atau ditemukan per tenant?
- Apakah klien menggunakan satu redirect URI bersama atau callback terpisah untuk setiap issuer?
- Apakah OIDC didukung, yang memerlukan validasi ID Token
iss,aud, dan nonce? - Apakah authorization server lama mengembalikan
iss, dan apakah masing-masing dapat menggunakan konfigurasi klien yang terisolasi? - Apakah PKCE wajib, dan apakah token endpoint harus menggunakan konfigurasi issuer asli?
Jawaban 30 detik
Simpan issuer yang tidak dapat diubah (immutable), dokumen discovery, authorization endpoint, token endpoint, JWKS, client ID, dan kebijakan redirect-URI untuk setiap authorization server. Saat otorisasi dimulai, buat state, nonce, dan PKCE serta simpan issuer yang diharapkan dalam rekaman sisi server yang berumur pendek (short-lived). Callback harus mewajibkan iss yang diizinkan dan bernilai sama dengan nilai yang diharapkan tersebut, lalu menukarkan kode hanya menggunakan konfigurasi issuer yang telah direkam. Nilai yang hilang, tidak dikenal, atau berkonflik akan menghentikan alur; klien tidak pernah menebak atau beralih secara diam-diam.
Jawaban mendalam
1. Menetapkan konfigurasi kepercayaan per issuer
Gunakan URL canonical issuer sebagai kunci konfigurasi, termasuk skema, host, port, dan path, serta bandingkan sesuai dengan aturan pasti dari issuer tersebut. Simpan authorization dan token endpoint, JWKS, kredensial klien, scope yang diizinkan, dan redirect URI.
Jika discovery diizinkan, wajibkan issuer dokumen tersebut cocok persis dengan nilai yang dikonfigurasi dan ambil dokumen tersebut melalui HTTPS. Issuer yang diberikan oleh pengguna tidak boleh memicu pengambilan metadata atau JWKS secara arbitrer.
2. Mengikat issuer saat memulai otorisasi
Hasilkan state yang tidak dapat diprediksi dan simpan state, issuer yang diharapkan, versi konfigurasi klien, redirect URI, PKCE challenge, dan waktu pembuatan dalam sesi sisi server atau penyimpanan berumur pendek. Browser hanya membawa referensi, bukan konfigurasi tenant yang dapat diubah.
URL otorisasi harus menggunakan redirect URI persis yang terdaftar untuk issuer dan klien tersebut. Jika tenant atau IdP dipilih secara dinamis, pilih dan catat di server; callback tidak boleh memilih konfigurasi awal secara retroaktif.
3. Memvalidasi iss pada authorization response
Parameter respons RFC 9207 iss harus berada dalam set issuer yang disetujui dan sama dengan issuer yang diharapkan dalam rekaman state. Server tanpa iss hanya boleh menggunakan jalur kompatibilitas dengan callback terisolasi, klien terisolasi, atau batas tepercaya; callback bersama tidak boleh menebak-nebak di antara semua issuer.
Validasi state, issuer, respons error, dan konteks pengalihan sebelum memproses kode. Tolak varian yang tidak dikenal, duplikat, atau variasi encoding dan besar-kecil huruf. Halaman error menampilkan kegagalan umum dan tidak pernah merefleksikan URL yang belum diverifikasi.
4. Mempertahankan token exchange pada issuer asli
Baca token endpoint, autentikasi klien, dan verifier PKCE dari rekaman state, jangan pernah dengan menggabungkan URL dari input callback. Jika respons token berisi issuer, ID Token, atau klaim identitas, bandingkan dengan issuer dan client ID asli.
PKCE mengikat penukar kode, state mengikat sesi browser, dan issuer mengikat authorization server. OIDC juga memerlukan validasi issuer, audience, tanda tangan, waktu, dan nonce pada ID Token; iss pada callback saja tidak cukup.
5. Mengamankan discovery, JWKS, dan rotasi
Discovery, token endpoint, dan JWKS harus tetap berada di dalam batas kepercayaan issuer yang disetujui. Gunakan caching JWKS yang terkontrol dan versi kunci; kid yang hilang dapat memicu satu kali penyegaran terbatas, tidak pernah mengakses URL arbitrer. Buat versi konfigurasi issuer sehingga state yang sedang berjalan (in-flight) terus menggunakan versi yang dicatat saat pembuatan.
Kegagalan discovery, ketidakcocokan issuer, kegagalan TLS, atau tanda tangan yang tidak dapat diverifikasi harus fail-closed untuk alur berisiko tinggi. Jangan mengalihkan token endpoint ke issuer lain demi ketersediaan.
6. Mencegah penyalahgunaan state dan kehabisan sumber daya
Beri rekaman state TTL yang singkat, konsumsi sekali pakai, dan batas konkurensi. Callback duplikat, state yang tidak dikenal atau kedaluwarsa, dan issuer yang salah akan membatalkan alur. Batasi parameter callback dan hindari mencatat JWT abnormal, URL, atau deskripsi error yang panjang ke log.
Lacak issuer yang hilang dan berkonflik, issuer yang tidak dikenal, replay state, kegagalan discovery, penyegaran JWKS, kegagalan PKCE, dan tingkat penyelesaian per issuer. Kelompokkan peringatan (alert) berdasarkan tenant dan issuer untuk memisahkan kesalahan konfigurasi dari serangan.
7. Memigrasikan authorization server lama
Inventarisasi kemampuan issuer dan callback, lalu terapkan RFC 9207 untuk server yang kompatibel. Server lama dapat menggunakan redirect URI terisolasi, klien terisolasi, atau proxy sisi server dengan pengikatan eksplisit, tanggal akhir dukungan, dan audit. Jangan mempertahankan callback bersama yang menebak issuer dari kode secara terus-menerus.
Selama peluncuran (rollout), bandingkan tingkat penyelesaian, error, latensi callback, dan konflik issuer. Jeda peluncuran tenant baru jika sinyal memburuk. Pertahankan rekaman state dan tombol rollback, tetapi jangan pernah menonaktifkan PKCE atau membuka kembali token endpoint yang tidak terikat.
Jawaban model
Untuk setiap authorization server, saya akan mempertahankan kebijakan issuer tetap, dokumen discovery, authorization endpoint, token endpoint, JWKS, klien, dan redirect-URI. Awal otorisasi membuat state, nonce, dan PKCE serta menyimpan issuer yang diharapkan dan versi konfigurasi di sisi server. Callback memvalidasi state dan RFC 9207 iss, mewajibkan nilai yang disetujui sama dengan issuer yang diharapkan; penukaran token kemudian hanya menggunakan endpoint dan kredensial klien yang telah dicatat.
Discovery issuer, OIDC ID Token issuer, audience, tanda tangan, dan nonce diperiksa kembali. Issuer yang hilang atau berkonflik, state yang kedaluwarsa atau berulang, dan kegagalan JWKS akan menghentikan alur daripada beralih secara diam-diam. IdP lama menggunakan callback terisolasi atau proxy dengan batas waktu. Pantau konflik issuer, replay state, kegagalan PKCE, dan penyelesaian per issuer.
Kesalahan umum
- Hanya memeriksa state dan berasumsi bahwa state tersebut mengidentifikasi authorization server.
- Membangun URL token atau JWKS langsung dari input issuer pada callback.
- Membiarkan nilai
issyang hilang atau tidak dikenal melanjutkan alur dengan mencoba setiap IdP. - Melewatkan pemeriksaan silang antara discovery issuer, ID Token issuer, dan token endpoint.
- Mempertahankan callback bersama dan tebakan issuer berbasis kode tanpa batas waktu selama migrasi.
- Menggambarkan PKCE, state, nonce, dan issuer binding sebagai satu kontrol yang sama.
- Menuliskan issuer yang belum divalidasi, JWT, atau URL error ke dalam log atau halaman tampilan.
Pertanyaan lanjutan dan jawaban
Mengapa state saja tidak dapat mencegah Mix-Up?
State mengikat sesi browser dan callback, tetapi klien masih dapat mengirimkan kode dengan state yang valid ke token endpoint yang salah jika tidak mengetahui issuer dari respons tersebut. Issuer binding menyediakan identitas server tersebut.
Bisakah alur dilanjutkan ketika callback tidak memiliki iss?
Hanya di bawah kebijakan kompatibilitas yang terisolasi secara eksplisit, seperti callback atau proxy terpisah per server lama. Callback bersama tidak boleh mengulang (iterate) seluruh issuer dan menebaknya.
Bolehkah pengguna memasukkan URL issuer?
Pilihan tersebut hanya boleh dipetakan ke issuer yang telah disetujui. Server tidak boleh mengambil metadata discovery atau JWKS untuk input arbitrer, yang akan menimbulkan risiko SSRF, phishing, dan trust-root.
Bagaimana Anda mencegah tertukarnya konfigurasi tenant?
Rekaman state berisi tenant, issuer, versi konfigurasi, dan redirect URI. Callback dan token exchange hanya membaca rekaman tersebut. Pembaruan konfigurasi tidak menimpa state yang sedang berjalan selama masa TTL-nya.
Apa lagi yang diperlukan untuk OIDC?
Validasi tanda tangan ID Token, issuer, audience, kedaluwarsa, waktu penerbitan (issued-at), nonce, dan konteks autentikasi yang diperlukan selain iss pada callback. Parameter callback tidak dapat menggantikan validasi ID Token.
Bagaimana Anda membuktikan bahwa migrasi tidak melemahkan keamanan?
Catat kebijakan yang diterapkan, waktu aktivasi, dan jenis callback per issuer. Uji issuer yang hilang dan dipalsukan, state lintas-tenant, penggantian endpoint, dan callback berulang, serta pantau hit fallback agar tetap nol atau berada dalam pengecualian yang disetujui.