Pertanyaan dan ruang lingkup
Klien layanan menjangkau API eksternal melalui beberapa explicit proxy. Beberapa permintaan mengembalikan 407 dan yang lainnya 401. Jelaskan batasan di antara keduanya, tantangan proxy hop-by-hop, tunnel CONNECT, penyimpanan kredensial, percobaan ulang (retry), dan observabilitas.
Ini adalah pertanyaan seputar jaringan dan keamanan backend. Jumlah proxy dan tingkat kegagalan adalah asumsi untuk latihan ini, bukan klaim pasar.
Hal yang diuji oleh pewawancara
- Apakah Anda memisahkan autentikasi resource-server dari autentikasi proxy next-hop.
- Apakah Anda menjelaskan di mana
Proxy-AuthenticatedanProxy-Authorizationdikonsumsi. - Apakah Anda menangani multiple hop, CONNECT, connection pool, dan rotasi kredensial.
- Apakah kredensial proxy tetap aman dari origin dan log.
Pertanyaan klarifikasi yang perlu diajukan
- Apakah klien menggunakan explicit proxy atau transparent proxy, dan apakah CONNECT dilibatkan?
- Skema apa yang digunakan oleh masing-masing proxy, dan apakah koneksi digunakan kembali (reused)?
- Bisakah klien dan gateway mempertahankan header 401 dan 407 yang asli?
- Apakah permintaan merupakan pembacaan yang aman (safe read) atau membuat, menagih (charge), atau mengubah status (mutate state)?
- Siapa yang merotasi kredensial, dan apakah tersedia backup egress?
Jawaban 30 detik
"Respons 407 adalah tantangan (challenge) dari proxy next-hop; respons 401 berasal dari sumber daya target. Saya mencatat pengidentifikasi hop dan permintaan, membaca Proxy-Authenticate, dan mengirimkan Proxy-Authorization yang cocok hanya ke proxy tersebut. Proxy inbound berikutnya mengonsumsinya; header ini tidak boleh sampai ke origin. Untuk CONNECT, lakukan autentikasi proxy sebelum membuat tunnel, lalu tangani 401 tingkat tunnel sebagai autentikasi origin. Saya hanya mencoba ulang permintaan yang aman untuk diulang (replay-safe) dan mengukur 407 berdasarkan proxy, skema, dan versi kredensial."
Desain langkah demi langkah
1. Pisahkan 401 dan 407
WWW-Authenticate dalam 401 mendeskripsikan tantangan sumber daya target, yang biasanya dijawab dengan Authorization. Proxy-Authenticate dalam 407 mendeskripsikan tantangan dari proxy next-hop, yang dijawab dengan Proxy-Authorization. Angka status yang mirip tidak menjadi alasan untuk berbagi cache atau menggunakan satu error handler yang sama.
2. Autentikasi satu per satu hop
Setiap proxy hanya menerima kredensial yang dimintanya. RFC 9110 mendefinisikan Proxy-Authorization untuk proxy inbound berikutnya yang memintanya; dalam sebuah rantai (chain), proxy pertama yang mengharapkan kredensial akan mengonsumsi field tersebut. Klien mengisolasi kredensial berdasarkan proxy atau koneksi dan tidak pernah meneruskan header proxy ke origin.
GET https://api.example/report HTTP/1.1
Host: api.example
Proxy-Authorization: Basic <proxy-credential>3. Tangani tunnel CONNECT
Untuk target HTTPS, klien mengirimkan CONNECT ke proxy terlebih dahulu. Setelah autentikasi proxy berhasil dan proxy mengembalikan 2xx, klien membuat tunnel TLS. Permintaan di dalamnya menjadi milik origin; 401 dari origin menggunakan Authorization dan tidak disalahartikan sebagai 407 proxy. Tantangan proxy yang gagal tetap menjadi bagian dari hop CONNECT.
4. Isolasi pool dan kredensial
Kunci pool mencakup alamat proxy, skema autentikasi, tenant, dan versi kredensial. Selama rotasi, hentikan penggunaan kembali koneksi lama atau lakukan autentikasi ulang sesuai kebutuhan proxy. Jangan letakkan Proxy-Authorization dalam template header lintas-permintaan atau mencatat nilainya dalam sistem penelusuran (tracing).
5. Batasi percobaan ulang dan efek samping
Setelah 407, coba lagi hanya jika tidak ada body yang tidak dapat dibatalkan (irreversible) yang terkirim atau operasinya aman untuk diputar ulang (replayable). Untuk POST, penagihan, atau pembuatan sumber daya, gunakan idempotency key bisnis dan periksa apakah server telah memproses upaya tersebut. Penanganan tantangan, pembaruan kredensial, dan pemutaran ulang harus menjadi peristiwa yang dapat diamati (observable), bukan perulangan (loop) tanpa batas.
6. Pasang instrumentasi diagnosis dan keamanan
Untuk setiap hop, catat identitas proxy, fase CONNECT, skema, versi kredensial, jumlah 407, hasil percobaan ulang, dan status akhir; simpan hanya ringkasan yang telah disunting (redacted). Bandingkan 401, 407, kegagalan TLS, penggunaan kembali pool, dan peralihan ke backup-egress untuk menemukan kesalahan target, kebijakan proxy, atau rotasi. Lakukan injeksi kegagalan (fault injection) untuk membuktikan bahwa perantara tidak dapat membocorkan atau menulis ulang header otorisasi origin.
Model jawaban berkualitas tinggi
"Saya membagi jalur menjadi lapisan proxy dan sumber daya. Proxy berikutnya menantang dengan 407 dan origin menantang dengan 401, masing-masing menggunakan Proxy-Authorization dan Authorization. Kredensial diisolasi berdasarkan identitas proxy; proxy inbound pertama yang mengharapkan field proxy akan mengonsumsinya, dan tidak akan pernah mencapai origin. HTTPS mengautentikasi proxy selama CONNECT sebelum lalu lintas tunnel. Pool dipisahkan berdasarkan proxy dan versi kredensial, serta rotasi akan menghentikan koneksi lama. Hanya permintaan yang aman yang diputar ulang setelah 407; efek samping dipulihkan dengan idempotensi dan kueri status. Metrik tingkat hop mengidentifikasi kesalahan."
Kesalahan umum
- Memperlakukan 407 sebagai 401 → kredensial melintasi batasan yang salah → tangani tantangan proxy dan sumber daya secara terpisah.
- Meneruskan kredensial proxy ke origin → rahasia bocor → biarkan proxy inbound berikutnya mengonsumsi dan menghapusnya.
- Mengirim lalu lintas tunnel sebelum CONNECT berhasil → status protokol salah → selesaikan autentikasi proxy dan terima 2xx CONNECT terlebih dahulu.
- Berbagi seluruh status autentikasi koneksi → tenant atau versi kredensial bercampur → isolasi berdasarkan proxy, tenant, dan versi.
- Mencoba ulang 407 tanpa batas → kesalahan dan efek samping berlipat ganda → batasi percobaan, uji keamanan pemutaran ulang (replay safety), dan kueri status.
Pertanyaan lanjutan dan jawabannya
Bisakah saya mengirim beberapa nilai Proxy-Authorization untuk beberapa proxy?
Jangan memperlakukan field tersebut sebagai daftar kredensial generik. Kirimkan apa yang diharapkan oleh proxy inbound saat ini; setelah proxy tersebut mengonsumsi field tersebut, tangani tantangan berikutnya sesuai dengan skema hop tersebut dan verifikasi bahwa implementasi memungkinkan penerusan yang aman.
Mengapa tidak mendiagnosis dari 407 terakhir saja?
Gateway dapat menulis ulang atau menelan respons perantara, dan penggunaan kembali koneksi dapat mengaitkan tantangan dengan permintaan yang salah. Pertahankan log hop, pengidentifikasi koneksi, dan tantangan asli untuk mengidentifikasi penerbit yang sebenarnya.
Bagaimana jika autentikasi proxy berhasil tetapi tunnel mengembalikan 401?
Pertahankan status autentikasi proxy dan jawab tantangan WWW-Authenticate dari origin dengan Authorization. Jangan mengirimkan ulang kredensial proxy atau menempatkan kredensial sumber daya di cache autentikasi proxy.