Wawancara Desain Sistem: Bagaimana Anda Akan Merancang Request-Bound Delegated-Authority Verifier?

Prompt dan cakupan

Rancang lapisan verifikasi otoritas terdelegasi untuk agen, beban kerja, atau batch job yang bertindak atas nama seseorang atau organisasi untuk membelanjakan uang, menggunakan sumber daya terukur, mengungkapkan data yang diatur, atau mengubah status produksi. Sistem harus membuktikan otoritas yang dibatasi sebelum memproses permintaan yang dilindungi. Prompt ini merujuk pada Internet-Draft HTTPAPI IETF dari tahun 2026; dokumen ini masih berupa pekerjaan yang sedang berjalan (work in progress), bukan RFC final, dan bukan protokol pembayaran.

Apa yang sedang diuji oleh pewawancara

Memisahkan autentikasi identitas, otorisasi terdelegasi, integritas permintaan, dan penyelesaian (settlement).
Merancang 401 challenge, 403 penolakan, nonce, kedaluwarsa, dan pengikatan permintaan (request binding).
Menangani replay, penggunaan lintas-tenant (cross-tenant), proksi, rotasi kunci, dan kemampuan audit.
Menegakkan anggaran, kebijakan, dan batasan fail-closed sebelum tindakan berdampak tinggi.

Pertanyaan untuk diklarifikasi sebelum menjawab

Apakah tindakan yang dilindungi berupa ekspor data, penulisan produksi, panggilan downstream, atau konsumsi anggaran?
Siapa yang mengoperasikan principal, penerbit (issuer), pemohon terdelegasi (delegated requester), dan pemverifikasi (verifier)?
Apakah otoritas harus terikat pada metode HTTP, URI target, digest permintaan, atau hanya cakupan sumber daya?
Apakah verifikasi offline diizinkan, dan bagaimana ketersediaan nonce serta clock skew ditangani?
Haruskah kegagalan menolak permintaan, memerlukan persetujuan manusia, atau diturunkan menjadi hanya-baca (read-only)?

Kerangka jawaban 30 detik

Bagi masalah menjadi empat lapisan: identitas yang ada membuktikan siapa pemohon; delegasi menyatakan atas nama siapa ia bertindak, apa yang boleh dilakukannya, dan batasannya; pengikatan permintaan membatasi bukti hanya untuk satu permintaan; kebijakan memutuskan apakah eksekusi diizinkan sekarang. Kembalikan 401 challenge jika tidak ada bukti yang dapat diterima dan 403 jika bukti dipahami tetapi tidak mencukupi. Sertakan penerbit, pemohon, principal, kedaluwarsa, nonce, metode, URI, digest, dan batasan anggaran. Eksekusi hanya setelah verifikasi, terapkan fail-closed, dan audit setiap penolakan.

Pembahasan mendalam langkah demi langkah

1. Tentukan peran dan batas kepercayaan

Principal adalah orang, organisasi, atau layanan. Pemohon terdelegasi adalah agen, perangkat, tugas, atau beban kerja. Penerbit menandatangani bukti untuk principal, dan pemverifikasi berada di sumber daya yang dilindungi atau gateway. OAuth Token Exchange atau sistem penerbitan lain dapat memperoleh bukti; pemverifikasi menangani challenge dan presentasi, bukan persetujuan (consent) atau penautan akun.

2. Rancang challenge dan respons

Tanpa bukti yang dapat diterima, kembalikan 401, WWW-Authenticate: Delegation, dan Cache-Control: no-store. Kembalikan 403 jika bukti valid secara sintaksis tetapi melampaui kebijakan lokal. Problem Details dapat menjelaskan kegagalan tersebut, tetapi bidang penjelasan tidak boleh melonggarkan challenge.

http

HTTP/1.1 401 Unauthorized
Cache-Control: no-store
WWW-Authenticate: Delegation realm="api.example",
  version=1, profile="budget", nonce="n-123", max-age=300

Pemverifikasi mengontrol nonce, profil, dan jendela kedaluwarsa sehingga bukti tidak dapat disalin di seluruh permintaan.

3. Ikat bukti ke permintaan di masa mendatang

Ikat setidaknya metode HTTP, origin tepercaya, URI target, digest permintaan, dan masa kedaluwarsa. Jika proksi menulis ulang Host atau path, rekonstruksi origin hanya dari konfigurasi gateway tepercaya; jangan pernah memercayai X-Forwarded-* yang tidak divalidasi. Tentukan kanonikalisasi untuk besar-kecil huruf metode, pengurutan kueri, dan persen pengodean (percent encoding).

json

{
  "principal": "org-42",
  "requester": "job-7",
  "method": "POST",
  "origin": "https://api.example",
  "target_hash": "sha-256:...",
  "nonce": "n-123",
  "expires": "2026-08-04T05:00:00Z",
  "limits": {"USD": 250}
}

4. Atur urutan verifikasi dan perilaku fail-closed

Urai versi dan format, lalu verifikasi tanda tangan, kepercayaan penerbit, kesegaran nonce, jendela waktu, pengikatan permintaan, dan anggaran lokal. Tolak jika dependensi tidak tersedia, CBOR bersifat non-deterministik, tanda tangan gagal, atau status nonce hilang. Verifikasi kredensial identitas dan bukti delegasi sebagai lapisan terpisah; satu bukti yang valid tidak boleh mengotorisasi kunci API yang tidak terkait.

5. Cegah replay dan penggunaan lintas-tenant

Simpan nonce dengan TTL pendek, konsumsi atomik, dan isolasi tenant. Digest permintaan dan origin target mencegah penyalinan satu bukti ke API lain. Tolak nonce yang digunakan kembali, batasi clock skew, dan gunakan bidang pengikatan yang identik untuk preflight dan permintaan akhir. Tindakan berisiko tinggi dapat memerlukan bukti sekali pakai dan persetujuan manusia.

6. Tegakkan anggaran dan kebijakan

Anggaran adalah profil otoritas, bukan pembayaran atau penyelesaian. Kebijakan dapat membatasi jumlah, unit layanan, cakupan data, lingkungan, dan panggilan downstream. Lakukan pendebetan dalam batas transaksi yang sama dengan tindakan, atau gunakan reservasi kompensasi (compensating reservation), sehingga permintaan serentak tidak dapat bersama-sama melampaui batas.

7. Operasikan kunci dan audit dengan aman

Penerbit memublikasikan kunci dan versi yang dapat dirotasi. Pemverifikasi dapat menyimpannya dalam cache tetapi harus mendukung pencabutan dan rotasi darurat. Audit principal, pemohon, target, hasil kebijakan, ID bukti, dan alasan penolakan; jangan pernah mencatat token lengkap, kunci privat, atau data sensitif. Lacak tingkat 401/403, replay nonce, latensi verifikasi, penolakan kebijakan, kelebihan anggaran, kegagalan rotasi kunci, dan waktu persetujuan.

Contoh jawaban berkualitas tinggi

Saya akan membagi sistem menjadi lapisan identitas, delegasi, pengikatan permintaan, dan kebijakan. OAuth atau penerbit lain membuktikan hubungan principal. Bukti delegasi membawa principal, pemohon, profil, kedaluwarsa, dan anggaran; pemverifikasi mengikatnya ke metode HTTP, origin tepercaya, URI target, digest permintaan, dan nonce yang akan dieksekusi.

Kembalikan 401 dengan WWW-Authenticate: Delegation dan no-store jika bukti tidak ada; kembalikan 403 jika bukti valid tetapi tidak mencukupi. Verifikasi format, tanda tangan dan kepercayaan penerbit, kesegaran nonce, jendela waktu, pengikatan permintaan, kebijakan tenant, dan anggaran dalam urutan tersebut. Setiap kegagalan tanda tangan, dependensi yang tidak tersedia, atau status nonce yang hilang akan mengalami fail-closed. Bukti tersebut tidak mendefinisikan pembayaran, menggantikan HTTP Message Signatures, atau mengimplementasikan penerbitan atau persetujuan OAuth.

Debet anggaran dalam transaksi tindakan atau reservasi kompensasi, dan konsumsi nonce yang terisolasi tenant secara atomik. Dukung rotasi kunci dan pencabutan darurat, sementara log hanya menyimpan ID bukti, principal, target, dan hasil. Uji replay, penyalinan lintas-tenant, penulisan ulang proksi, pengeluaran berlebih serentak, dan rotasi kunci. Tujuannya adalah untuk membuktikan "siapa yang bertindak atas nama siapa, dan apa yang boleh dilakukannya terhadap permintaan persis ini" sebelum tindakan yang berdampak terjadi.

Kesalahan umum

Memperlakukan bukti delegasi sebagai identitas umum, penerbitan OAuth, atau protokol pembayaran.
Menerbitkan token berumur panjang tanpa pengikatan metode, URI, digest, nonce, atau kedaluwarsa.
Mengizinkan permintaan ketika dependensi tanda tangan tidak tersedia.
Memercayai nilai X-Forwarded-* yang ditulis ulang proksi atau tidak tepercaya untuk target.
Mencatat seluruh kredensial dalam log atau mendebet setelah tindakan, meninggalkan celah replay dan pengeluaran berlebih.

Pertanyaan lanjutan dan tanggapan

Mengapa menggunakan 401 dan 403?

401 berarti bukti hilang, tidak valid, atau tidak lengkap, sehingga klien dapat memperoleh bukti baru dari challenge tersebut. 403 berarti bukti dipahami tetapi otoritas, anggaran, atau kebijakan lokal tidak mencukupi; mencoba lagi tidak akan membantu.

Bagaimana jika layanan nonce sementara tidak tersedia?

Terapkan fail-closed untuk permintaan berisiko tinggi dan kembalikan kesalahan diagnostik no-store. Hanya tindakan hanya-baca berisiko rendah yang dinilai secara eksplisit yang boleh memiliki fallback terbatas; nonce lama yang di-cache bukanlah status sekali pakai.

Bagaimana cara kerjanya dengan OAuth?

OAuth Token Exchange atau GNAP dapat memperoleh materi delegasi. Pemverifikasi tetap memeriksa bukti yang terikat permintaan secara independen. Verifikasi token identitas dan bukti delegasi secara terpisah agar cakupan yang didelegasikan tidak disalahartikan sebagai semua izin token identitas.

Apakah ini protokol pembayaran?

Bukan. Profil anggaran dapat menyatakan batas jumlah atau unit layanan, sedangkan penyelesaian, rel pembayaran, dan semantik HTTP 402 bersifat eksternal. Pemverifikasi hanya memutuskan apakah tindakan yang dilindungi memenuhi kebijakan delegasi.