Wawancara Backend: Bagaimana Anda merancang pertukaran token OAuth untuk panggilan layanan yang didelegasikan?

Masalah dan konteks

Sebuah API gateway SaaS multi-tenant memanggil layanan penagihan atas nama pengguna yang telah masuk. Platform identitas menerbitkan access token upstream untuk gateway; layanan penagihan hanya menerima audience miliknya sendiri. Gateway memerlukan token downstream yang lebih sempit sembari mempertahankan pernyataan yang dapat diaudit mengenai siapa yang bertindak atas nama siapa.

Rancang endpoint pertukaran, aturan validasi, pemetaan klaim, caching, penanganan kesalahan, pencabutan, dan pemantauan. Asumsikan gateway adalah klien sisi server yang terkontrol dan browser tidak pernah memegang token downstream. Layanan penagihan harus menolak token yang ditujukan untuk layanan lain.

Rancangan Anda harus mempertahankan lima invarian:

1. Layanan pertukaran hanya menerima subject token tervalidasi yang diizinkan untuk dipertukarkan.
2. Audience, scope, tenant, dan jangkauan sumber daya yang baru tidak boleh lebih luas daripada otorisasi upstream.
3. Subject dan actor tetap dapat dibedakan dan dilacak; suatu layanan tidak dapat menyamar sebagai pengguna.
4. Layanan downstream hanya memercayai issuer, audience, dan kunci penandatanganannya sendiri.
5. Pencabutan, kedaluwarsa, rotasi kunci, dan batas audit memiliki batasan waktu yang terukur.

Apa yang dievaluasi oleh pewawancara

Mulailah dengan membedakan token exchange, token forwarding, impersonasi, dan delegasi. RFC 8693 mendefinisikan Security Token Service berbasis HTTP/JSON. Sebuah permintaan dapat berisi subject_token dan secara opsional sebuah actor_token; responsnya memperluas respons token-endpoint OAuth yang normal. Protokol itu sendiri tidak memberikan otoritas yang lebih luas.

Sinyal berikutnya adalah kedisiplinan audience. Gateway tidak boleh meneruskan bearer token yang ditujukan untuk dirinya sendiri ke layanan penagihan, pencarian, dan ekspor. Setiap token downstream memerlukan satu audience dan hanya scope yang diperlukan untuk panggilan tersebut.

Sinyal ketiga adalah hubungan proksi. Pertukaran hanya diizinkan ketika kebijakan menyatakan bahwa actor boleh bertindak atas nama subject. Klaim seperti may_act dan act memerlukan issuer tepercaya atau sumber kebijakan lokal. Menyalin sub atau tenant_id sembarang yang disediakan klien ke dalam token baru merupakan sebuah eskalasi.

Terakhir, bahas mode kegagalan: cache otorisasi yang basi (stale), downstream yang memeriksa tanda tangan tetapi tidak memeriksa audience, token dalam log, refresh token yang diserahkan ke gateway, dan pencabutan upstream yang baru efektif setelah TTL downstream berakhir.

Pertanyaan untuk diklarifikasi terlebih dahulu

• Siapa subject dan siapa actor? Di sini subject adalah pengguna dan actor adalah API gateway; impersonasi akun layanan memerlukan kebijakan eksplisit.
• Siapa yang menggunakan token yang dipertukarkan? Apakah penagihan adalah satu-satunya audience, atau apakah beberapa sumber daya diizinkan? Beberapa audience memperbesar blast radius.
• Bagaimana scope dikurangi? Upstream mungkin memiliki billing:read billing:write; mana yang dibutuhkan oleh permintaan ini?
• Di mana batas tenant diperiksa? Penyimpanan identitas, sesi, dan sumber daya mana yang otoritatif? Jangan pernah memercayai field tenant pada body permintaan.
• Berapa target waktu pencabutan? Misalnya, hentikan pertukaran baru dalam waktu lima detik dan batasi token downstream yang ada hingga dua menit.
• Apakah gateway memerlukan refresh token? Panggilan yang didelegasikan biasanya memerlukan access token berumur pendek; refresh token berumur panjang memerlukan tinjauan ancaman terpisah.

Jawaban 30 detik

“Saya akan meminta gateway memanggil endpoint token standar dengan subject_token pengguna, actor_token gateway, audience penagihan yang tetap, dan scope minimum. Layanan pertukaran memvalidasi issuer, tanda tangan, exp, nbf, autentikasi klien, kebijakan delegasi subject, dan status tenant. Tabel kebijakan memetakan scope upstream ke scope downstream yang diizinkan. Token baru hanya berisi audience penagihan, waktu kedaluwarsa yang singkat, konteks tenant, dan hubungan subject/actor; token tersebut tidak pernah menyalin klaim yang belum diverifikasi.

Layanan penagihan hanya memercayai issuer, kunci penandatanganan, dan audience miliknya serta melakukan otorisasi tingkat sumber daya. Keputusan pertukaran dapat di-cache secara singkat, tetapi peristiwa pencabutan dan TTL yang singkat harus memenuhi target yang ditetapkan. Body token, permintaan pertukaran, dan rahasia actor disunting (redacted). Kesalahan bersifat generik; catatan audit menyimpan ID permintaan, subject, actor, audience, scope, dan versi kebijakan.”

Rancangan langkah demi langkah

Langkah 1: Tentukan batas token dan kepercayaan

Layanan pertukaran adalah authorization server atau STS tepercaya, bukan pembantu gateway sembarangan. Layanan ini mengonfigurasi issuer upstream yang diizinkan, JWKS, metode autentikasi klien, audience downstream, dan versi kebijakan. Gateway mengautentikasi dengan mTLS, JWT private-key, atau metode lain yang disetujui; string statis saja bukan merupakan bukti otoritas delegasi.

Permintaan minimum dapat terlihat 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 memperlakukan pemohon sebagai klien dalam pertukaran. Resource server dapat bertindak sementara sebagai klien tersebut untuk menukar token yang masuk dengan token yang sesuai untuk layanan backend. Peran tersebut tidak dengan sendirinya memberikan izin baru.

Langkah 2: Validasi subject dan actor berdasarkan sumber

Pilih validator berdasarkan jenis token, lalu periksa daftar izin algoritma, issuer, exp, nbf, klien yang diperlukan, jenis token, dan status pencabutan. Cache JWKS berdasarkan issuer dan rotasi berdasarkan kid; kunci yang tidak dikenal dapat memicu refresh terkontrol, jangan pernah menurunkan versi algoritma (algorithm downgrade).

Subject adalah pengguna atau beban kerja (workload) yang diwakili. Actor adalah gateway yang benar-benar memulai pertukaran. Kebijakan harus menjawab apakah actor ini boleh bertindak untuk subject ini pada audience ini, bukan hanya sekadar apakah actor tersebut merupakan layanan yang dikenal. may_act pada RFC 8693 dapat mengekspresikan actor yang diotorisasi; token yang dipertukarkan dapat mengekspresikan actor saat ini dengan act. Kedua klaim memerlukan issuer tepercaya atau kebijakan lokal.

Jangan perlakukan sub, tenant_id, atau roles pada body permintaan sebagai fakta identitas. Bangun kembali konteks dari token yang divalidasi dan direktori tenant yang otoritatif, serta tolak data subject yang hilang atau berkonflik.

Langkah 3: Hitung otorisasi yang lebih sempit secara monoton

Ekspresikan otorisasi sebagai irisan yang dibatasi:

issued_scope = requested_scope
             ∩ subject_allowed_scope
             ∩ actor_allowed_scope
             ∩ audience_policy_scope
             ∩ tenant_state_scope

Tolak scope yang diminta jika kosong atau terlalu luas; jangan diam-diam mencetak default yang lebih luas. Audience berasal dari registri layanan, bukan URL sembarang yang disediakan oleh gateway. Setiap audience mengikat klaim, scope, TTL, dan jenis sumber daya yang diizinkan.

Status tenant, pengguna yang dinonaktifkan, kepemilikan akun penagihan, dan tindakan berisiko tinggi mungkin memerlukan pemeriksaan kebijakan daring. tenant_id pada token hanyalah bagian dari konteks yang divalidasi; layanan sumber daya tetap membandingkannya dengan kepemilikan. Jika sebuah permintaan membutuhkan beberapa layanan, lebih baik lakukan beberapa pertukaran berumur pendek daripada satu audience universal.

Langkah 4: Terbitkan token downstream berumur pendek yang dapat diverifikasi

Access token harus memuat iss, sub, aud, exp, iat, scope, identitas tenant, ID klien, versi kebijakan, dan hubungan actor. Waktu kedaluwarsanya tidak boleh melebihi sisa masa berlaku upstream atau jendela risiko bisnis. Jangan mengembalikan refresh token sebagai hasil pertukaran biasa.

Layanan penagihan mem-pin issuer, audience, JWKS, dan algoritma yang diizinkan serta melakukan otorisasi sumber daya pada setiap permintaan. Validasi tanda tangan tanpa validasi aud memungkinkan satu layanan menerima token yang diterbitkan untuk layanan lain. Token dengan batasan pengirim (sender-constrained token) dapat lebih memastikan bahwa menyalin nilai bearer tidaklah cukup.

Langkah 5: Koordinasikan cache, pencabutan, dan rotasi kunci

Cache metadata issuer, JWKS, dan hasil kebijakan berumur pendek hanya jika kuncinya mencakup issuer, subject, actor, audience, scope, tenant, dan versi kebijakan. Jangan pernah menggunakan kembali keputusan izin dari satu tenant untuk tenant lainnya. Pencabutan pertama-tama memperbarui otoritas dan memublikasikan peristiwa pembatalan (invalidation); endpoint pertukaran berhenti menerbitkan dalam waktu lima detik, dan token downstream baru memiliki TTL maksimum dua menit. Penagihan dapat memilih introspeksi atau verifikasi TTL pendek berdasarkan risiko.

Uji pesan pembatalan yang hilang, restart node, dan jeda replikasi. Rotasi JWKS membutuhkan tumpang tindih yang terikat dan kid yang dapat dilacak. Mencabut kunci penandatanganan memengaruhi setiap token yang ditandatanganinya; ini bukan pengganti pencabutan di tingkat subject.

Langkah 6: Tangani kesalahan, replay, dan ketersediaan

Kembalikan kesalahan kelas invalid_grant atau invalid_target yang seragam untuk issuer yang tidak dikenal, kedaluwarsa, audience yang salah, subject yang tidak dapat didelegasikan, scope yang tidak memadai, dan kebijakan yang tidak tersedia. Jangan ungkapkan apakah suatu subject ada; simpan ID permintaan dan kode alasan yang aman secara internal.

Permintaan pertukaran berisi materi bearer dan tidak boleh masuk ke URL, log biasa, atribut trace, atau laporan kesalahan. Jika token upstream dapat di-replay, penyerang yang mencuri lalu lintas gateway dapat mengulangi pertukaran. TLS, sender constraints, TTL pendek, rate limit, dan sinyal risiko mempersempit celah tersebut. Jika penyimpanan kebijakan tidak tersedia, gunakan fail-closed untuk operasi tulis berisiko tinggi. Fallback baca berisiko rendah apa pun memerlukan usia batas kedaluwarsa kebijakan usang (stale-policy age) maksimum.

Langkah 7: Audit rantai subject dan batas tenant

Catat request_id, subject, actor, klien, tenant, audience, scope yang diminta dan diterbitkan, ID token, versi kebijakan, ID kunci issuer, dan keputusan. Jangan pernah mencatat body token. Log downstream mereferensikan ID token dan ID permintaan sehingga panggilan gateway dapat dihubungkan ke tindakan pengguna.

Layanan sumber daya tidak boleh hanya memercayai header X-Tenant-ID dari gateway. Layanan ini membaca konteks tenant dari token yang ditandatangani, lalu memeriksa kepemilikan sumber daya, status akun penagihan, dan aturan persetujuan. Tambahkan uji adversarial untuk akses lintas-tenant, perilaku confused deputy, perluasan scope, audience yang salah, dan replay token lama.

Langkah 8: Rilis dengan bukti bertahap

Daftarkan audience dan scope tetap untuk satu tenant uji dan buktikan bahwa token lama tidak dapat mengakses penagihan. Lakukan canary untuk issuer dan kunci baru sambil mengamati tingkat penolakan pertukaran, latensi kebijakan, TTL token, kesalahan audience, hit cache, dan penyebaran pencabutan. Perluas ke tenant produksi hanya setelah hasil pengukuran terpenuhi.

Sediakan tombol rollback yang menghentikan penerbitan baru dan memulihkan konfigurasi klien yang diketahui baik. Jangan melakukan rollback dengan menonaktifkan pemeriksaan audience downstream atau menghapus catatan audit.

Contoh jawaban berkualitas tinggi

“Saya memperlakukan layanan pertukaran sebagai STS tepercaya. Gateway mengirimkan subject_token pengguna yang diautentikasi klien, actor_token miliknya sendiri, audience penagihan yang tetap, dan scope terkecil. Layanan memvalidasi setiap issuer, tanda tangan, klaim waktu, jenis token, klien, dan aturan delegasi, kemudian mengiriskan scope yang diminta dengan kebijakan subject, actor, audience, dan status tenant. Layanan menolak audience sembarang dan permintaan apa pun yang memperluas otoritas.

Token downstream hanya untuk penagihan, kedaluwarsa tidak lebih lama dari token upstream, dan mencatat subject, actor, tenant, scope, versi kebijakan, dan ID token. Penagihan mem-pin issuer, JWKS, dan audience-nya serta tetap melakukan otorisasi tenant tingkat sumber daya. Token dan permintaan pertukaran tidak pernah masuk ke log; catatan audit hanya berisi metadata rantai dan keputusan.

Pencabutan memperbarui otoritas dan menyiarkan pembatalan, menghentikan pertukaran baru dalam waktu lima detik. Token downstream bertahan paling lama dua menit, dengan introspeksi atau validasi TTL pendek yang dipilih berdasarkan risiko. Kunci cache mencakup semua dimensi identitas dan kebijakan, dan rotasi JWKS memiliki tumpang tindih yang terikat. Pertukaran token mempersempit otoritas dan mempertahankan akuntabilitas; ini tidak menyalin identitas pengguna ke setiap layanan.”

Kesalahan umum

• Meneruskan bearer token upstream. Audience-nya salah dan kebocoran akan menyebar secara lateral; tukarkan token yang sempit per sumber daya.
• Hanya memeriksa tanda tangan. Tanda tangan yang valid tidak membuktikan issuer, audience, atau scope.
• Menggabungkan subject dan actor. Downstream tidak dapat membedakan pengguna dari layanan proksi, sehingga audit dan pencabutan kehilangan maknanya.
• Memercayai tenant_id dari body permintaan. Penyerang dapat memilih tenant lain; turunkan dari identitas yang divalidasi dan kepemilikan sumber daya.
• Mengasumsikan actor yang diizinkan bertukar dapat mewakili siapa saja. Delegasi memerlukan kebijakan eksplisit dan sumber tepercaya.
• Menerbitkan refresh token secara default. Gateway memerlukan access token berumur pendek; kredensial berumur panjang memperbesar celah risiko.
• Melakukan caching tanpa semua dimensi atau dengan TTL yang panjang. Otorisasi dapat melintasi tenant atau bertahan melebihi waktu pencabutan; batasi kunci, versi, dan propagasi.
• Mencatat token atau permintaan pertukaran dalam log. Nilai bearer dapat di-replay; catat hanya ID token, metadata publik, dan kode alasan.
• Menggunakan satu token untuk setiap downstream. Audience dan scope menjadi terlalu luas; lakukan pertukaran secara terpisah.
• Hanya menguji skenario sukses. Kedaluwarsa, audience yang salah, pencabutan, rotasi JWKS, restart, dan kegagalan kebijakan mengungkap batasan sistem yang sebenarnya.

Pertanyaan lanjutan dan jawaban referensi

Masalah apa yang diselesaikan oleh may_act dan act?

may_act menyatakan actor mana yang diotorisasi oleh subject token untuk bertindak; act menyatakan siapa yang saat ini bertindak atas nama siapa di dalam token baru. Keduanya tidak menggantikan pemeriksaan tanda tangan, issuer, audience, atau otorisasi lokal, dan keduanya memerlukan sumber tepercaya.

Mengapa tidak meneruskan token pengguna ke penagihan?

Token upstream biasanya menargetkan gateway dan mungkin mencakup beberapa sumber daya. Meneruskannya akan memperbesar paparan audience dan izin. Pertukaran menerbitkan token yang berumur pendek dan dapat diaudit hanya untuk penagihan.

Haruskah penagihan menggunakan introspeksi daring?

Hal ini bergantung pada tujuan pencabutan, lalu lintas, dan ketersediaan. Operasi tulis berisiko tinggi dapat menggunakan introspeksi; operasi baca biasa dapat menggunakan JWT ber-TTL pendek. Ukur keterlambatan terburuk; caching luring dan pencabutan instan tidak dapat diklaim keduanya secara bersamaan tanpa mekanisme yang terikat.

Bagaimana jika layanan kebijakan tidak tersedia?

Gunakan pendekatan fail-closed untuk pertukaran berisiko tinggi. Pembacaan berisiko rendah dapat menggunakan cache kebijakan usang yang dibatasi secara eksplisit, dengan mekanisme fallback yang terlihat dalam pemantauan dan audit. Sikap default allow mengubah insiden ketersediaan menjadi eskalasi hak istimewa.

Bagaimana Anda mencegah tertukarnya cache multi-tenant?

Sertakan issuer, subject, actor, tenant, audience, scope, dan versi kebijakan dalam kunci cache, dan tetap periksa kepemilikan sumber daya. Kunci yang hanya didasarkan pada ID pengguna atau audience dapat menggunakan kembali keputusan satu tenant untuk tenant lainnya.

Token upstream dicabut tetapi token downstream masih valid. Lalu bagaimana?

Hentikan pertukaran baru dengan segera dan biarkan downstream melakukan introspeksi atau menerima peristiwa pembatalan sesuai tingkat risiko. Jika hanya memverifikasi secara luring, batasi TTL pada batas maksimum yang diterima dan audit operasi dalam interval tersebut; operasi yang telah di-commit tidak dapat ditarik kembali.

Bagaimana cara melakukan rollback dengan aman?

Hentikan pertukaran baru, tarik audience atau versi kebijakan yang bermasalah, pertahankan validasi terbatas untuk kunci penandatanganan lama, dan pulihkan konfigurasi klien yang diketahui baik. Jangan pernah menonaktifkan pemeriksaan audience atau menghapus bukti audit sebagai jalan pintas.