Temu duga Backend: Bagaimanakah anda mereka bentuk pertukaran token OAuth untuk panggilan perkhidmatan yang diwakilkan?

Masalah dan konteks

Sebuah get laluan API SaaS multi-tenant memanggil perkhidmatan pengebilan bagi pihak pengguna yang telah log masuk. Platform identiti mengeluarkan token akses upstream untuk get laluan; perkhidmatan pengebilan hanya menerima audiensnya sendiri. Get laluan memerlukan token downstream yang lebih sempit sambil mengekalkan penyata yang boleh diaudit tentang siapa yang bertindak bagi pihak siapa.

Reka bentuk titik akhir pertukaran, peraturan pengesahan, pemetaan tuntutan (claim mapping), caching, pengendalian ralat, pembatalan, dan pemantauan. Andaikan get laluan ialah klien bahagian pelayan yang terkawal dan pelayar tidak pernah memegang token downstream. Perkhidmatan pengebilan mesti menolak token yang ditujukan untuk perkhidmatan lain.

Reka bentuk anda harus mengekalkan lima invarian:

1. Perkhidmatan pertukaran hanya menerima token subjek yang telah disahkan yang dibenarkan untuk ditukar.
2. Audiens, skop, tenant, dan capaian sumber yang baharu tidak boleh lebih luas daripada kebenaran upstream.
3. Subjek dan actor kekal boleh dibezakan dan dijejaki; perkhidmatan tidak boleh menyamar sebagai pengguna.
4. Perkhidmatan downstream hanya mempercayai pengeluar (issuer), audiens, dan kunci menandatangani miliknya sendiri.
5. Pembatalan, tamat tempoh, putaran kunci, dan sempadan audit mempunyai had masa yang boleh diukur.

Perkara yang dinilai oleh penemu duga

Mulakan dengan membezakan pertukaran token, pemajuan token, penyamaran (impersonation), dan perwakilan (delegation). RFC 8693 mentakrifkan Security Token Service berasaskan HTTP/JSON. Permintaan boleh mengandungi subject_token dan secara pilihan actor_token; responsnya melanjutkan respons titik akhir token OAuth biasa. Protokol itu sendiri tidak memberikan kuasa yang lebih luas.

Isyarat seterusnya ialah disiplin audiens. Get laluan tidak boleh memajukan token pembawa (bearer token) yang dialamatkan kepada dirinya sendiri ke perkhidmatan pengebilan, carian, dan eksport. Setiap token downstream memerlukan satu audiens dan hanya skop yang diperlukan untuk panggilan tersebut.

Isyarat ketiga ialah hubungan proksi. Pertukaran hanya dibenarkan apabila dasar menyatakan bahawa actor boleh bertindak bagi pihak subjek. Tuntutan seperti may_act dan act memerlukan pengeluar yang dipercayai atau sumber dasar tempatan. Menyalin sub atau tenant_id sewenang-wenangnya yang dibekalkan oleh klien ke dalam token baharu merupakan satu peningkatan keistimewaan.

Akhir sekali, bincangkan mod kegagalan: cache kebenaran lapuk (stale), perkhidmatan downstream yang menyemak tandatangan tetapi bukan audiens, token dalam log, token penyegaran (refresh token) yang diserahkan kepada get laluan, dan pembatalan upstream yang kekal berkuat kuasa sehingga TTL downstream tamat.

Soalan untuk dijelaskan terlebih dahulu

• Siapakah subjek dan siapakah actor? Di sini subjek ialah pengguna dan actor ialah get laluan API; penyamaran akaun perkhidmatan memerlukan dasar yang jelas.
• Siapakah yang menggunakan token yang ditukar? Adakah pengebilan satu-satunya audiens, atau adakah berbilang sumber dibenarkan? Berbilang audiens membesarkan radius impak (blast radius).
• Bagaimanakah skop dikurangkan? Upstream mungkin mempunyai billing:read billing:write; yang manakah diperlukan oleh permintaan ini?
• Di manakah sempadan tenant disemak? Stor identiti, sesi, dan sumber manakah yang berwibawa? Jangan sekali-kali mempercayai medan tenant dalam badan permintaan.
• Apakah sasaran masa pembatalan? Contohnya, hentikan pertukaran baharu dalam masa lima saat dan hadkan token downstream sedia ada kepada dua minit.
• Adakah get laluan memerlukan token penyegaran? Panggilan yang diwakilkan biasanya memerlukan token akses jangka pendek; token penyegaran jangka panjang memerlukan semakan ancaman yang berasingan.

Jawapan 30 saat

“Saya akan meminta get laluan memanggil titik akhir token standard dengan subject_token pengguna, actor_token get laluan, audiens pengebilan yang tetap, dan skop minimum. Perkhidmatan pertukaran mengesahkan pengeluar, tandatangan, exp, nbf, pengesahan klien, dasar perwakilan subjek, dan status tenant. Jadual dasar memetakan skop upstream kepada skop downstream yang dibenarkan. Token baharu hanya mengandungi audiens pengebilan, tempoh luput yang singkat, konteks tenant, dan hubungan subjek/actor; ia tidak pernah menyalin tuntutan yang tidak disahkan.

Perkhidmatan pengebilan hanya mempercayai pengeluar, kunci menandatangani, dan audiens miliknya serta melakukan kebenaran pada peringkat sumber. Keputusan pertukaran boleh dicache secara singkat, tetapi peristiwa pembatalan dan TTL yang pendek mesti memenuhi sasaran yang ditetapkan. Badan token, permintaan pertukaran, dan rahsia actor disunting (redacted). Ralat adalah bersifat generik; rekod audit menyimpan ID permintaan, subjek, actor, audiens, skop, dan versi dasar.”

Reka bentuk langkah demi langkah

Langkah 1: Tentukan sempadan token dan kepercayaan

Perkhidmatan pertukaran ialah pelayan kebenaran (authorization server) atau STS yang dipercayai, bukannya pembantu get laluan sewenang-wenangnya. Ia mengkonfigurasi pengeluar upstream yang dibenarkan, JWKS, kaedah pengesahan klien, audiens downstream, dan versi dasar. Get laluan mengesahkan identiti dengan mTLS, JWT kunci peribadi, atau kaedah lain yang diluluskan; rentetan statik sahaja bukanlah bukti kuasa perwakilan.

Permintaan minimum boleh kelihatan seperti ini:

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
subject_token=...
subject_token_type=urn:ietf:params:oauth:token-type:access_token
actor_token=...
actor_token_type=urn:ietf:params:oauth:token-type:access_token
audience=https://billing.internal
scope=billing:read

RFC 8693 menganggap peminta sebagai klien dalam pertukaran. Pelayan sumber boleh bertindak sementara sebagai klien tersebut untuk menukar token yang diterima dengan token yang sesuai untuk perkhidmatan backend. Peranan itu sendiri tidak memberikan kebenaran baharu secara automatik.

Langkah 2: Sahkan subjek dan actor mengikut sumber

Pilih pengesah mengikut jenis token, kemudian semak senarai algoritma yang dibenarkan, pengeluar, exp, nbf, klien yang diperlukan, jenis token, dan status pembatalan. Cache JWKS mengikut pengeluar dan putarkan mengikut kid; kunci yang tidak diketahui boleh mencetuskan penyegaran terkawal, jangan sesekali menurunkan gred algoritma (algorithm downgrade).

Subjek ialah pengguna atau beban kerja (workload) yang diwakili. Actor ialah get laluan yang sebenarnya memulakan pertukaran. Dasar mesti menjawab sama ada actor ini boleh bertindak untuk subjek ini pada audiens ini, bukan sekadar sama ada actor tersebut ialah perkhidmatan yang dikenali. may_act RFC 8693 boleh menyatakan actor yang dibenarkan; token yang ditukar boleh menyatakan actor semasa dengan act. Kedua-dua tuntutan memerlukan pengeluar yang dipercayai atau dasar tempatan.

Jangan anggap sub, tenant_id, atau roles dalam badan permintaan sebagai fakta identiti. Bina semula konteks daripada token yang disahkan dan direktori tenant yang berwibawa serta tolak data subjek yang hilang atau bercanggah.

Langkah 3: Kira kebenaran yang lebih sempit secara monotonik

Nyatakan kebenaran sebagai persilangan yang dikekang:

issued_scope = requested_scope
             ∩ subject_allowed_scope
             ∩ actor_allowed_scope
             ∩ audience_policy_scope
             ∩ tenant_state_scope

Tolak skop yang diminta jika ia kosong atau terlalu luas; jangan senyap-senyap mengeluarkan lalai yang lebih luas. Audiens berasal daripada pendaftaran perkhidmatan, bukannya URL sewenang-wenangnya yang dibekalkan oleh get laluan. Setiap audiens mengikat tuntutan, skop, TTL, dan jenis sumber yang dibenarkan.

Status tenant, pengguna yang dinyahdayakan, pemilikan akaun pengebilan, dan tindakan berisiko tinggi mungkin memerlukan semakan dasar dalam talian. tenant_id dalam token hanyalah sebahagian daripada konteks yang disahkan; perkhidmatan sumber masih membandingkannya dengan pemilikan. Jika sesuatu permintaan memerlukan beberapa perkhidmatan, utamakan beberapa pertukaran jangka pendek daripada satu audiens sejagat.

Langkah 4: Keluarkan token downstream jangka pendek yang boleh disahkan

Token akses harus membawa iss, sub, aud, exp, iat, skop, identiti tenant, ID klien, versi dasar, dan hubungan actor. Tempoh luputnya tidak boleh melebihi baki hayat upstream atau tetingkap risiko perniagaan. Jangan kembalikan token penyegaran sebagai hasil pertukaran biasa.

Perkhidmatan pengebilan menetapkan (pin) pengeluar, audiens, JWKS, dan algoritma yang dibenarkan serta melaksanakan kebenaran sumber pada setiap permintaan. Pengesahan tandatangan tanpa pengesahan aud membolehkan satu perkhidmatan menerima token yang dikeluarkan untuk perkhidmatan lain. Token dengan kekangan penghantar (sender-constrained token) boleh memastikan lagi bahawa menyalin nilai pembawa adalah tidak mencukupi.

Langkah 5: Selaraskan cache, pembatalan, dan putaran kunci

Cache metadata pengeluar, JWKS, dan hasil dasar jangka pendek hanya apabila kuncinya merangkumi pengeluar, subjek, actor, audiens, skop, tenant, dan versi dasar. Jangan sesekali menggunakan semula keputusan kebenaran satu tenant untuk tenant yang lain. Pembatalan terlebih dahulu mengemas kini pihak berkuasa dan menerbitkan peristiwa ketidaksahan (invalidation event); titik akhir pertukaran berhenti mengeluarkan token dalam masa lima saat, dan token downstream baharu mempunyai TTL maksimum dua minit. Pengebilan boleh memilih introspeksi atau pengesahan TTL pendek mengikut risiko.

Uji mesej ketidaksahan yang hilang, permulaan semula nod, dan kelengahan replikasi. Putaran JWKS memerlukan pertindihan yang terhad dan kid yang boleh dijejaki. Membatalkan kunci menandatangani mempengaruhi setiap token yang ditandatanganinya; ia bukan pengganti untuk pembatalan pada peringkat subjek.

Langkah 6: Kendalikan ralat, penyiaran semula, dan ketersediaan

Kembalikan ralat kelas invalid_grant atau invalid_target yang seragam untuk pengeluar yang tidak diketahui, luput, audiens yang salah, subjek yang tidak boleh diwakilkan, skop yang tidak mencukupi, dan dasar yang tidak tersedia. Jangan dedahkan sama ada subjek wujud; simpan ID permintaan dan kod sebab yang selamat secara dalaman.

Permintaan pertukaran mengandungi bahan pembawa dan tidak boleh dimasukkan ke dalam URL, log biasa, atribut surihan (trace attributes), atau laporan ralat. Jika token upstream boleh disiarkan semula, penyerang yang mencuri trafik get laluan boleh mengulangi pertukaran. TLS, kekangan penghantar, TTL pendek, had kadar (rate limits), dan isyarat risiko mengurangkan tetingkap ancaman tersebut. Jika storan dasar tidak tersedia, gunakan pendekatan fail-closed untuk operasi tulis berisiko tinggi. Sebarang sandaran bacaan berisiko rendah memerlukan had umur dasar lapuk (stale-policy age) maksimum.

Langkah 7: Audit rantaian subjek dan sempadan tenant

Catatkan request_id, subjek, actor, klien, tenant, audiens, skop yang diminta dan dikeluarkan, ID token, versi dasar, ID kunci pengeluar, dan keputusan. Jangan sekali-kali mencatat badan token. Log downstream merujuk ID token dan ID permintaan supaya panggilan get laluan boleh disambungkan kepada tindakan pengguna.

Perkhidmatan sumber tidak boleh hanya mempercayai pengepala X-Tenant-ID daripada get laluan. Ia membaca konteks tenant daripada token yang ditandatangani, kemudian menyemak pemilikan sumber, status akaun pengebilan, dan peraturan kelulusan. Tambahkan ujian adversarial untuk akses rentas tenant, tingkah laku confused deputy, peluasan skop, audiens yang salah, dan penyiaran semula token lama.

Langkah 8: Lancarkan secara berperingkat dengan bukti

Daftarkan audiens dan skop tetap untuk satu tenant ujian dan buktikan bahawa token lama tidak boleh mengakses pengebilan. Lakukan pelancaran kenari (canary) untuk pengeluar dan kunci baharu sambil memerhatikan kadar penolakan pertukaran, kependaman dasar, TTL token, ralat audiens, capaian cache (cache hits), dan perambatan pembatalan. Kembangkan ke tenant pengeluaran hanya selepas ukuran tersebut stabil dan memuaskan.

Sediakan suis gulung balik (rollback) yang menghentikan pengeluaran baharu dan memulihkan konfigurasi klien yang diketahui baik. Jangan gulung balik dengan melumpuhkan semakan audiens downstream atau memadamkan rekod audit.

Contoh jawapan berkualiti tinggi

“Saya menganggap perkhidmatan pertukaran sebagai STS yang dipercayai. Get laluan menyerahkan subject_token pengguna yang disahkan klien, actor_token miliknya sendiri, audiens pengebilan yang tetap, dan skop yang paling kecil. Perkhidmatan mengesahkan setiap pengeluar, tandatangan, tuntutan masa, jenis token, klien, dan peraturan perwakilan, kemudian memotong (intersect) skop yang diminta dengan dasar subjek, actor, audiens, dan status tenant. Ia menolak audiens sewenang-wenangnya dan sebarang permintaan yang meluaskan kuasa.

Token downstream hanya untuk pengebilan, tamat tempoh tidak lewat daripada token upstream, dan merekodkan subjek, actor, tenant, skop, versi dasar, dan ID token. Pengebilan menetapkan pengeluar, JWKS, dan audiensnya serta masih melakukan kebenaran tenant pada peringkat sumber. Token dan permintaan pertukaran tidak pernah memasuki log; rekod audit hanya mengandungi metadata rantaian dan keputusan.

Pembatalan mengemas kini pihak berkuasa dan menyiarkan ketidaksahan, menghentikan pertukaran baharu dalam masa lima saat. Token downstream bertahan paling lama dua minit, dengan introspeksi atau pengesahan TTL pendek yang dipilih mengikut risiko. Kunci cache merangkumi semua dimensi identiti dan dasar, dan putaran JWKS mempunyai pertindihan yang terhad. Pertukaran token mengecilkan kuasa dan mengekalkan kebertanggungjawaban; ia tidak menyalin identiti pengguna ke setiap perkhidmatan.”

Kesilapan biasa

• Memajukan token pembawa upstream. Audiensnya salah dan kebocoran akan merebak secara lateral; tukar token sempit bagi setiap sumber.
• Hanya menyemak tandatangan. Tandatangan yang sah tidak membuktikan pengeluar, audiens, atau skop.
• Menggabungkan subjek dan actor. Downstream tidak dapat membezakan pengguna daripada perkhidmatan proksi, menyebabkan audit dan pembatalan kehilangan makna.
• Mempercayai tenant_id daripada badan permintaan. Penyerang boleh memilih tenant lain; terbitkan ia daripada identiti yang disahkan dan pemilikan sumber.
• Menganggap actor yang dibenarkan menukar token boleh mewakili sesiapa sahaja. Perwakilan memerlukan dasar yang jelas dan sumber yang dipercayai.
• Mengeluarkan token penyegaran secara lalai. Get laluan memerlukan token akses jangka pendek; kelayakan jangka panjang membesarkan tetingkap risiko.
• Melakukan caching tanpa semua dimensi atau dengan TTL yang panjang. Kebenaran boleh merentasi tenant atau bertahan melebihi masa pembatalan; batasi kunci, versi, dan perambatan.
• Mencatat token atau permintaan pertukaran dalam log. Nilai pembawa boleh disiarkan semula; catat ID token, metadata awam, dan kod sebab sahaja.
• Menggunakan satu token untuk setiap downstream. Audiens dan skop menjadi terlalu luas; lakukan pertukaran secara berasingan.
• Hanya menguji kejayaan. Tempoh tamat, audiens yang salah, pembatalan, putaran JWKS, permulaan semula nod, dan kegagalan dasar mendedahkan sempadan sebenar sistem.

Soalan susulan dan jawapan rujukan

Apakah masalah yang diselesaikan oleh may_act dan act?

may_act menyatakan actor mana yang dibenarkan oleh token subjek untuk bertindak; act menyatakan siapa yang bertindak bagi pihak siapa dalam token baharu. Kedua-duanya tidak menggantikan semakan tandatangan, pengeluar, audiens, atau kebenaran tempatan, dan kedua-duanya memerlukan sumber yang dipercayai.

Mengapakah tidak memajukan token pengguna terus ke pengebilan?

Token upstream biasanya menyasarkan get laluan dan mungkin merangkumi beberapa sumber. Pemajuan membesarkan pendedahan audiens dan kebenaran. Pertukaran mengeluarkan token jangka pendek yang boleh diaudit hanya untuk pengebilan.

Patutkah pengebilan menggunakan introspeksi dalam talian?

Ia bergantung pada matlamat pembatalan, trafik, dan ketersediaan. Operasi tulis berisiko tinggi boleh menggunakan introspeksi; operasi baca biasa boleh menggunakan JWT ber-TTL pendek. Ukur kelewatan terburuk; caching luar talian dan pembatalan serta-merta tidak boleh dituntut kedua-duanya tanpa mekanisme yang terhad.

Bagaimana jika perkhidmatan dasar tidak tersedia?

Gunakan pendekatan fail-closed untuk pertukaran berisiko tinggi. Bacaan berisiko rendah boleh menggunakan cache dasar lapuk yang dihadkan secara jelas, dengan mekanisme sandaran yang kelihatan dalam pemantauan dan audit. Kebenaran secara lalai (default allow) mengubah insiden ketersediaan menjadi peningkatan keistimewaan.

Bagaimanakah anda mengelakkan kekeliruan cache multi-tenant?

Sertakan pengeluar, subjek, actor, tenant, audiens, skop, dan versi dasar dalam kunci cache, dan tetap semak pemilikan sumber. Kunci yang hanya berdasarkan ID pengguna atau audiens boleh menggunakan semula keputusan satu tenant untuk tenant yang lain.

Token upstream telah dibatalkan tetapi token downstream masih sah. Apakah tindakannya?

Hentikan pertukaran baharu serta-merta dan biarkan perkhidmatan downstream melakukan introspeksi atau menggunakan peristiwa ketidaksahan mengikut tahap risiko. Jika ia hanya mengesahkan secara luar talian, hadkan TTL pada tetingkap maksimum yang diterima dan audit operasi dalam selang masa tersebut; operasi yang telah dilakukan (committed) tidak boleh ditarik balik.

Bagaimanakah anda melakukan gulung balik dengan selamat?

Hentikan pertukaran baharu, tarik balik audiens atau versi dasar yang bermasalah, kekalkan pengesahan terhad untuk kunci menandatangani lama, dan pulihkan konfigurasi klien yang diketahui baik. Jangan sekali-kali melumpuhkan semakan audiens atau memadamkan bukti audit sebagai jalan pintas.