Temuduga Backend: Bagaimanakah anda mempertahankan sistem daripada OAuth Mix-Up dengan pelbagai authorization server?

Gesaan dan konteks

Sebuah klien SaaS berintegrasi dengan enterprise IdP, public IdP, dan authorization server rakan kongsi. Penyerang cuba membuat klien menganggap permintaan yang dimulakan pada pelayan A sebagai respons daripada pelayan B, yang berpotensi menghantar kod ke token endpoint yang salah atau menggunakan konfigurasi klien yang salah. Reka bentuk pertahanan Mix-Up yang merangkumi pengikatan issuer (issuer binding), authorization response, token exchange, penemuan metadata, ralat, dan migrasi.

RFC 9207 mentakrifkan parameter respons iss supaya authorization server dapat mengenal pasti dirinya sendiri dalam OAuth authorization response. RFC 9700 menyenaraikan pengenalpastian issuer sebagai pertahanan Mix-Up. Matlamatnya adalah untuk mengikat "pengguna yang kembali" kepada "authorization server mana yang menyelesaikan aliran ini", dan bukannya bergantung pada state semata-mata.

Perkara yang diuji oleh penemuduga

• Pengecaman kekeliruan kod, token-endpoint, dan konfigurasi klien dalam aliran berbilang issuer.
• Mengikat issuer kepada state, redirect URI, PKCE, dan rekod permintaan kebenaran (authorization request).
• Semakan ketekalan merentas metadata penemuan (discovery), URL issuer, TLS, JWKS, dan token endpoint.
• Pengendalian selamat bagi nilai iss yang hilang, tidak diketahui, berkonflik, atau dipalsukan.
• Pelan migrasi yang menyokong IdP lama tanpa mengekalkan sandaran (fallback) yang tidak selamat buat selamanya.

Soalan penjelasan

1. Adakah senarai issuer statik, didaftarkan secara dinamik, atau ditemui bagi setiap tenant?
2. Adakah klien menggunakan satu redirect URI yang dikongsi atau callback berasingan untuk setiap issuer?
3. Adakah OIDC disokong, yang memerlukan pengesahan iss, aud, dan nonce bagi ID Token?
4. Adakah authorization server legasi mengembalikan iss, dan bolehkah setiap satu menggunakan konfigurasi klien yang terpencil?
5. Adakah PKCE diwajibkan, dan adakah token endpoint mesti menggunakan konfigurasi issuer asal?

Jawapan 30 saat

Simpan issuer yang tidak boleh diubah (immutable), dokumen discovery, authorization endpoint, token endpoint, JWKS, ID klien, dan dasar redirect-URI untuk setiap authorization server. Pada permulaan kebenaran, jana state, nonce, dan PKCE serta kekalkan issuer yang dijangkakan dalam rekod bahagian pelayan (server-side) yang jangka hayatnya pendek. Callback mesti memerlukan iss yang dibenarkan dan sama dengan nilai yang dijangkakan itu, kemudian menebus kod hanya menggunakan konfigurasi issuer yang direkodkan. Nilai yang hilang, tidak diketahui, atau berkonflik akan menghentikan aliran; klien tidak akan sesekali meneka atau beralih secara senyap.

Jawapan mendalam

1. Wujudkan konfigurasi kepercayaan bagi setiap issuer

Gunakan URL canonical issuer sebagai kunci konfigurasi, termasuk skema, hos, port, dan laluan, serta bandingkannya mengikut peraturan tepat issuer tersebut. Simpan authorization dan token endpoint, JWKS, kelayakan klien, skop yang dibenarkan, dan redirect URI.

Apabila discovery dibenarkan, syaratkan issuer dokumen sepadan tepat dengan nilai yang dikonfigurasi dan ambil dokumen tersebut melalui HTTPS. Issuer yang dibekalkan pengguna tidak boleh menyebabkan pengambilan metadata atau JWKS sewenang-wenangnya.

2. Ikat issuer semasa memulakan kebenaran

Jana state yang tidak dapat diramalkan dan kekalkan state, issuer yang dijangkakan, versi konfigurasi klien, redirect URI, cabaran PKCE, dan masa penciptaan dalam sesi bahagian pelayan atau stor jangka pendek. Penyemak imbas hanya membawa rujukan, bukan konfigurasi tenant yang boleh diubah.

URL kebenaran mesti menggunakan redirect URI tepat yang didaftarkan untuk issuer dan klien tersebut. Jika tenant atau IdP dipilih secara dinamik, pilih dan rekodkannya pada pelayan; callback tidak boleh memilih konfigurasi awal secara retroaktif.

3. Sahkan iss authorization response

Parameter respons RFC 9207 iss mesti berada dalam set issuer yang diluluskan dan sama dengan issuer yang dijangkakan dalam rekod state. Pelayan tanpa iss hanya boleh menggunakan laluan keserasian dengan callback terpencil, klien terpencil, atau sempadan yang dipercayai; callback yang dikongsi tidak boleh meneka merentasi setiap issuer.

Sahkan state, issuer, respons ralat, dan konteks pengalihan sebelum memproses kod. Tolak varian yang tidak diketahui, pendua, atau perbezaan pengekodan dan huruf besar/kecil. Halaman ralat memaparkan kegagalan generik dan tidak sekali-kali memaparkan semula URL yang tidak disahkan.

4. Kekalkan pertukaran token pada issuer asal

Baca token endpoint, pengesahan klien, dan pengesah PKCE daripada rekod state, jangan sekali-kali dengan mencantumkan URL daripada input callback. Jika respons token mengandungi issuer, ID Token, atau tuntutan identiti, bandingkannya dengan issuer dan ID klien asal.

PKCE mengikat penebus kod, state mengikat sesi penyemak imbas, dan issuer mengikat authorization server. OIDC juga memerlukan pengesahan issuer, audiens, tandatangan, masa, dan nonce bagi ID Token; iss callback sahaja tidak mencukupi.

5. Lindungi discovery, JWKS, dan putaran kunci

Discovery, token endpoint, dan JWKS mesti kekal di dalam sempadan kepercayaan issuer yang diluluskan. Gunakan penimbalan (caching) JWKS yang terkawal dan versi kunci; kid yang hilang boleh mencetuskan satu penyegaran terhad, bukan akses URL sewenang-wenangnya. Gandakan versi konfigurasi issuer supaya state yang sedang berjalan terus menggunakan versi yang direkodkan semasa penciptaan.

Kegagalan discovery, ketidakpadanan issuer, kegagalan TLS, atau tandatangan yang tidak dapat disahkan akan gagal-tutup (fail closed) untuk aliran berisiko tinggi. Jangan tukar token endpoint ke issuer lain atas sebab ketersediaan.

6. Cegah penyalahgunaan state dan pengurangan sumber

Berikan rekod state TTL yang singkat, penggunaan sekali sahaja, dan had keserentakan. Callback pendua, state yang tidak diketahui atau tamat tempoh, dan issuer yang salah akan membatalkan aliran. Hadkan parameter callback dan elakkan daripada mencatat JWT yang tidak normal, URL, atau penerangan ralat yang panjang ke dalam log.

Jejak issuer yang hilang dan berkonflik, issuer yang tidak diketahui, ulangan state, kegagalan discovery, penyegaran JWKS, kegagalan PKCE, dan penyiapan mengikut issuer. Kumpulkan amaran mengikut tenant dan issuer untuk memisahkan kesilapan konfigurasi daripada serangan.

7. Migrasikan authorization server legasi

Inventori keupayaan issuer dan callback, kemudian kuat kuasakan RFC 9207 untuk pelayan yang serasi. Pelayan legasi boleh menggunakan redirect URI terpencil, klien terpencil, atau proksi bahagian pelayan dengan pengikatan eksplisit, tarikh tamat, dan audit. Jangan kekalkan callback dikongsi yang meneka issuer daripada kod untuk tempoh tanpa had.

Semasa pelaksanaan berperingkat, bandingkan penyiapan, ralat, kependaman callback, dan konflik issuer. Jeda peluncuran tenant baharu apabila isyarat merosot. Kekalkan rekod state dan suis pengunduran (rollback switch), tetapi jangan sekali-kali menyahdayakan PKCE atau membuka semula token endpoint yang tidak terikat.

Jawapan model

Bagi setiap authorization server, saya akan mengekalkan issuer tetap, dokumen discovery, authorization endpoint, token endpoint, JWKS, klien, dan dasar redirect-URI. Permulaan kebenaran mencipta state, nonce, dan PKCE serta menyimpan issuer yang dijangkakan dan versi konfigurasi pada bahagian pelayan. Callback mengesahkan state dan RFC 9207 iss, yang memerlukan nilai diluluskan yang sama dengan issuer yang dijangkakan; pertukaran token kemudiannya hanya menggunakan endpoint dan kelayakan klien yang direkodkan.

Discovery issuer, OIDC ID Token issuer, audiens, tandatangan, dan nonce disemak sekali lagi. Issuer yang hilang atau berkonflik, state yang tamat tempoh atau berulang, dan kegagalan JWKS akan menghentikan aliran dan bukannya beralih secara senyap. IdP legasi menggunakan callback terpencil atau proksi dengan tarikh akhir. Pantau konflik issuer, ulangan state, kegagalan PKCE, dan penyiapan mengikut issuer.

Kesilapan biasa

• Hanya menyemak state dan menganggap ia mengenal pasti authorization server.
• Membina URL token atau JWKS secara terus daripada input issuer callback.
• Membiarkan nilai iss yang hilang atau tidak diketahui diteruskan dengan mencuba setiap IdP.
• Melepaskan semakan silang antara discovery issuer, ID Token issuer, dan token endpoint.
• Mengekalkan callback yang dikongsi dan tekaan issuer berasaskan kod untuk tempoh tanpa had semasa migrasi.
• Menghuraikan PKCE, state, nonce, dan pengikatan issuer sebagai satu kawalan tunggal.
• Menulis issuer yang tidak disahkan, JWT, atau URL ralat ke dalam log atau halaman paparan.

Soalan susulan dan jawapan

Mengapakah state sahaja tidak dapat menghalang Mix-Up?

State mengikat sesi penyemak imbas dan callback, tetapi klien masih boleh menghantar kod dengan state yang sah ke token endpoint yang salah jika ia tidak mengetahui issuer respons tersebut. Pengikatan issuer membekalkan identiti pelayan berkenaan.

Bolehkah aliran diteruskan apabila callback tidak mempunyai iss?

Hanya di bawah dasar keserasian yang diasingkan secara eksplisit, seperti callback atau proksi berasingan bagi setiap pelayan legasi. Callback yang dikongsi tidak boleh mengulangi (iterate) setiap issuer dan meneka.

Bolehkah pengguna memasukkan URL issuer?

Pemilihan tersebut hanya boleh dipetakan kepada issuer yang diluluskan. Pelayan tidak boleh mengambil discovery atau JWKS untuk input sewenang-wenangnya, yang akan mewujudkan risiko SSRF, pancingan data (phishing), dan trust-root.

Bagaimanakah anda menghalang kekeliruan konfigurasi tenant?

Rekod state mengandungi tenant, issuer, versi konfigurasi, dan redirect URI. Callback dan pertukaran token hanya membaca rekod tersebut. Kemas kini konfigurasi tidak menulis ganti state yang sedang berjalan semasa TTL-nya.

Apakah perkara lain yang diperlukan untuk OIDC?

Sahkan tandatangan ID Token, issuer, audiens, tarikh luput, masa dikeluarkan, nonce, dan konteks pengesahan yang diperlukan selain iss callback. Parameter callback tidak boleh menggantikan pengesahan ID Token.

Bagaimanakah anda membuktikan bahawa migrasi tidak melemahkan keselamatan?

Rekod dasar yang dikuatkuasakan, masa pengaktifan, dan jenis callback bagi setiap issuer. Uji issuer yang hilang dan dipalsukan, state rentas-tenant, penggantian endpoint, dan callback berulang, serta pantau capaian sandaran (fallback hits) supaya ia kekal sifar atau berada dalam pengecualian yang diluluskan.