Temu Duga Reka Bentuk Sistem: Bagaimanakah Anda Akan Mereka Bentuk Pengesah Kuasa Terwakil Terikat-Permintaan?

Gesaan dan skop

Reka bentuk lapisan pengesahan kuasa terwakil untuk ejen, beban kerja atau tugas kelompok (batch job) yang bertindak bagi pihak seseorang atau organisasi untuk membelanjakan wang, menggunakan sumber bermeter, mendedahkan data terkawal, atau mengubah keadaan pengeluaran. Sistem mesti membuktikan kuasa yang terikat sebelum memproses permintaan yang dilindungi. Gesaan ini merujuk kepada Draf Internet HTTPAPI IETF dari tahun 2026; ia masih dalam proses pembangunan (work in progress), bukan RFC muktamad, dan bukan protokol pembayaran.

Perkara yang diuji oleh penemu duga

• Memisahkan pengesahan identiti, kebenaran terwakil, integriti permintaan, dan penyelesaian (settlement).
• Mereka bentuk cabaran 401, penolakan 403, nonce, tamat tempoh, dan pengikatan permintaan (request binding).
• Mengendalikan main semula (replay), penggunaan semula merentas penyewa (cross-tenant), proksi, giliran kunci (key rotation), dan kebolehkauditannya.
• Menguatkuasakan belanjawan, dasar, dan sempadan gagal-tutup (fail-closed) sebelum tindakan berimpak tinggi.

Soalan untuk dijelaskan sebelum menjawab

1. Adakah tindakan yang dilindungi itu merupakan eksport data, penulisan pengeluaran, panggilan hiliran (downstream), atau penggunaan belanjawan?
2. Siapakah yang mengendalikan prinsipal, pengeluar (issuer), peminta terwakil (delegated requester), dan pengesah (verifier)?
3. Adakah kuasa mesti diikat pada kaedah HTTP, URI sasaran, ringkasan permintaan (digest), atau hanya skop sumber?
4. Adakah pengesahan luar talian dibenarkan, dan bagaimanakah ketersediaan nonce serta serongan jam (clock skew) dikendalikan?
5. Patutkah kegagalan menolak permintaan, memerlukan kelulusan manusia, atau diturunkan taraf kepada baca sahaja?

Rangka kerja jawapan 30 saat

Bahagikan masalah kepada empat lapisan: identiti sedia ada membuktikan siapa peminta; perwakilan menyatakan untuk siapa ia bertindak, apa yang boleh dilakukannya, dan hadnya; pengikatan permintaan mengehadkan bukti kepada satu permintaan sahaja; dasar memutuskan sama ada pelaksanaan dibenarkan sekarang. Kembalikan cabaran 401 apabila tiada bukti yang boleh diterima dan 403 apabila bukti difahami tetapi tidak mencukupi. Sertakan pengeluar, peminta, prinsipal, tamat tempoh, nonce, kaedah, URI, digest, dan had belanjawan. Laksanakan hanya selepas pengesahan, gunakan mod gagal-tutup, dan audit setiap penolakan.

Analisis mendalam langkah demi langkah

1. Tentukan peranan dan sempadan kepercayaan

Prinsipal ialah seseorang, organisasi, atau perkhidmatan. Peminta terwakil ialah ejen, peranti, tugas, atau beban kerja. Pengeluar menandatangani bukti untuk prinsipal, dan pengesah berada pada sumber yang dilindungi atau get laluan (gateway). OAuth Token Exchange atau sistem pengeluaran lain boleh memperoleh bukti tersebut; pengesah mengendalikan cabaran dan pembentangan, bukan persetujuan (consent) atau pemautan akaun.

2. Reka bentuk cabaran dan respons

Tanpa bukti yang boleh diterima, kembalikan 401, WWW-Authenticate: Delegation, dan Cache-Control: no-store. Kembalikan 403 apabila bukti sah dari segi sintaks tetapi melebihi dasar tempatan. Problem Details boleh menerangkan kegagalan tersebut, tetapi medan penjelasan tidak boleh melonggarkan cabaran.

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

Pengesah mengawal nonce, profil, dan tetingkap tamat tempoh supaya bukti tidak boleh disalin merentas permintaan.

3. Ikat bukti pada permintaan masa hadapan

Ikat sekurang-kurangnya kaedah HTTP, asal (origin) yang dipercayai, URI sasaran, digest permintaan, dan tamat tempoh. Jika proksi menulis semula Host atau laluan, bina semula origin hanya daripada konfigurasi get laluan yang dipercayai; jangan sekali-kali mempercayai X-Forwarded-* yang tidak disahkan. Tentukan pengkanonikan (canonicalization) untuk huruf besar/kecil kaedah, susunan pertanyaan, dan pengekodan peratus (percent encoding).

{
  "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. Tetapkan susunan pengesahan dan tingkah laku gagal-tutup

Huraikan versi dan format, kemudian sahkan tandatangan, kepercayaan pengeluar, kesegaran nonce, tetingkap masa, pengikatan permintaan, dan belanjawan tempatan. Tolak apabila kebergantungan tidak tersedia, CBOR bukan deterministik, tandatangan gagal, atau keadaan nonce hilang. Sahkan kelayakan identiti dan bukti perwakilan sebagai lapisan berasingan; satu bukti yang sah tidak boleh membenarkan kunci API yang tidak berkaitan.

5. Cegah main semula dan penggunaan semula merentas penyewa

Simpan nonce dengan TTL yang pendek, penggunaan atomik, dan pengasingan penyewa. Digest permintaan dan sasaran origin menghalang penyalinan satu bukti ke API lain. Tolak nonce yang diguna semula, hadkan serongan jam, dan gunakan medan pengikatan yang sama untuk pra-penerbangan (preflight) dan permintaan akhir. Tindakan berisiko tinggi boleh memerlukan bukti sekali guna dan kelulusan manusia.

6. Kuat kuasakan belanjawan dan dasar

Belanjawan ialah profil kuasa, bukan pembayaran atau penyelesaian. Dasar boleh mengehadkan jumlah, unit perkhidmatan, skop data, persekitaran, dan panggilan hiliran. Debit dalam sempadan transaksi yang sama seperti tindakan tersebut, atau gunakan tempahan pampasan (compensating reservation), supaya permintaan serentak tidak melebihi had secara bersama.

7. Kendalikan kunci dan audit dengan selamat

Pengeluar menerbitkan kunci dan versi yang boleh digilirkan. Pengesah boleh menyimpannya dalam cache tetapi mesti menyokong pembatalan dan giliran kecemasan. Audit prinsipal, peminta, sasaran, keputusan dasar, ID bukti, dan sebab penolakan; jangan sekali-kali merekodkan token penuh, kunci peribadi, atau data sensitif dalam log. Jejaki kadar 401/403, main semula nonce, kependaman pengesahan, penolakan dasar, lebihan belanjawan, kegagalan giliran kunci, dan masa kelulusan.

Contoh jawapan berkualiti tinggi

Saya akan membahagikan sistem kepada lapisan identiti, perwakilan, pengikatan permintaan, dan dasar. OAuth atau pengeluar lain membuktikan hubungan prinsipal. Bukti perwakilan membawa prinsipal, peminta, profil, tamat tempoh, dan belanjawan; pengesah mengikatnya pada kaedah HTTP, origin yang dipercayai, URI sasaran, digest permintaan, dan nonce yang akan dilaksanakan.

Kembalikan 401 dengan WWW-Authenticate: Delegation dan no-store apabila bukti tiada; kembalikan 403 apabila ia sah tetapi tidak mencukupi. Sahkan format, tandatangan dan kepercayaan pengeluar, kesegaran nonce, tetingkap masa, pengikatan permintaan, dasar penyewa, dan belanjawan mengikut urutan tersebut. Sebarang kegagalan tandatangan, kebergantungan yang tidak tersedia, atau kehilangan keadaan nonce akan mencetuskan mod gagal-tutup. Bukti tersebut tidak mentakrifkan pembayaran, menggantikan HTTP Message Signatures, atau melaksanakan pengeluaran atau persetujuan OAuth.

Debit belanjawan dalam transaksi tindakan atau tempahan pampasan, dan gunakan nonce yang diasingkan mengikut penyewa secara atomik. Sokong giliran kunci dan pembatalan kecemasan, manakala log hanya mengekalkan ID bukti, prinsipal, sasaran, dan hasil. Uji main semula, penyalinan merentas penyewa, penulisan semula proksi, perbelanjaan berlebihan serentak, dan giliran kunci. Matlamatnya adalah untuk membuktikan "siapa yang bertindak untuk siapa, dan apa yang boleh dilakukannya terhadap permintaan tepat ini" sebelum tindakan berimpak itu berlaku.

Kesilapan biasa

• Menganggap bukti perwakilan sebagai identiti umum, pengeluaran OAuth, atau protokol pembayaran.
• Mengeluarkan token jangka panjang tanpa pengikatan kaedah, URI, digest, nonce, atau tamat tempoh.
• Membenarkan permintaan apabila kebergantungan tandatangan tidak tersedia.
• Mempercayai nilai X-Forwarded-* yang ditulis semula oleh proksi atau tidak dipercayai untuk sasaran.
• Merekodkan kelayakan penuh dalam log atau mendebit selepas tindakan, lalu meninggalkan ruang untuk main semula dan perbelanjaan berlebihan.

Soalan susulan dan respons

Mengapa menggunakan kedua-dua 401 dan 403?

401 bermakna bukti tiada, tidak sah, atau tidak lengkap, jadi klien boleh mendapatkan bukti baharu daripada cabaran tersebut. 403 bermakna bukti difahami tetapi kuasa, belanjawan, atau dasar tempatan tidak mencukupi; mencuba semula tidak akan membantu.

Bagaimana jika perkhidmatan nonce tidak tersedia buat sementara waktu?

Gunakan mod gagal-tutup untuk permintaan berisiko tinggi dan kembalikan ralat diagnostik no-store. Hanya tindakan baca sahaja berisiko rendah yang dinilai secara eksplisit boleh mempunyai sandaran terhad; nonce lama yang dicache bukanlah keadaan sekali guna.

Bagaimanakah ini berfungsi dengan OAuth?

OAuth Token Exchange atau GNAP boleh memperoleh bahan perwakilan. Pengesah tetap menyemak bukti terikat-permintaan secara bebas. Sahkan token identiti dan bukti perwakilan secara berasingan supaya skop terwakil tidak disalah anggap sebagai semua kebenaran token identiti.

Adakah ini protokol pembayaran?

Tidak. Profil belanjawan boleh menyatakan had jumlah atau unit perkhidmatan, manakala penyelesaian, rel pembayaran, dan semantik HTTP 402 adalah luaran. Pengesah hanya memutuskan sama ada tindakan yang dilindungi itu memenuhi dasar perwakilan.