1. Pertanyaan dan Konteks
Beberapa resource server API menerima token akses yang diterbitkan oleh server otorisasi. Mereka perlu mengetahui apakah suatu token aktif, klien mana yang memilikinya, scope apa saja yang dimilikinya, dan kapan masa berlakunya habis. Tim keamanan juga memerlukan pencabutan cepat untuk token yang dicuri. Desain ini harus menyeimbangkan antara pencabutan waktu nyata (real-time), latensi rendah, dan ketersediaan layanan otorisasi.
2. Apa yang Dinilai oleh Pewawancara
- Apakah Anda memahami semantik introspeksi RFC 7662 dan pencabutan RFC 7009.
- Apakah cache, event pencabutan, dan versi dapat mencegah hasil aktif yang usang menyembunyikan pencabutan.
- Apakah Anda membedakan token opaque, validasi JWT lokal, dan proof-of-possession seperti DPoP.
- Apakah kebijakan pemadaman (outage), percobaan ulang (retry), isolasi penyewa (tenant), dan audit didefinisikan secara eksplisit.
3. Pertanyaan Klarifikasi Sebelum Menjawab
- Apakah token tersebut berupa token akses berumur pendek, refresh token, atau keduanya?
- Apakah Anda mencabut satu token, sebuah izin (grant), sesi pengguna, atau seluruh klien?
- Berapa batas keterlambatan propagasi pencabutan yang dapat diterima oleh resource server?
- Apakah Anda perlu mengikat kunci klien atau kunci publik DPoP untuk mencegah pemutaran ulang (replay) bearer token yang disalin?
4. Kerangka Jawaban 30 Detik
Gunakan endpoint, sumber kebenaran (source of truth), cache, propagasi pencabutan, dan kebijakan kegagalan.
Server otorisasi mengekspos endpoint introspeksi dan pencabutan yang dilindungi. Penyimpanan status (state store) menyimpan hash token, klien, scope, masa berlaku, dan versi pencabutan. Resource server menyimpan cache hasil aktif untuk TTL yang singkat dan berlangganan event pencabutan untuk segera menghapus entri. Scope berisiko tinggi menerapkan fail-closed selama pemadaman otorisasi; permintaan berisiko rendah dapat menggunakan cache positif yang belum kedaluwarsa untuk sementara waktu. Kueri, pencabutan, dan kegagalan diaudit.
5. Pembahasan Mendalam Langkah demi Langkah
Langkah 1: Menentukan Status Token dan Otorisasi Endpoint
Hanya resource server tepercaya yang boleh memanggil introspeksi. Kembalikan field yang diperlukan seperti active, client_id, username, scope, exp, iat, dan sub tanpa mengekspos data identitas yang tidak perlu. Endpoint pencabutan mengautentikasi pemanggil dan tipe tokennya, mengikuti RFC 7009 untuk pencabutan berulang, dan tidak mengungkapkan apakah token yang sudah tidak valid sebelumnya memang ada.
Langkah 2: Merancang Penyimpanan Status dan Indeks
Gunakan sidik jari (fingerprint) atau hash token sebagai kunci. Simpan waktu penerbitan, masa berlaku, ID grant, klien, scope, versi status, dan alasan pencabutan. Beri indeks pada ID grant untuk pencabutan massal; jauhkan teks biasa yang sensitif dari log. Lakukan sharding berdasarkan tenant atau hash agar satu klien tidak menjadi partisi yang terlalu padat (hot partition).
Langkah 3: Menangani Cache dan Propagasi Pencabutan
Simpan cache hasil positif untuk TTL yang singkat; hindari cache negatif yang berdurasi lama. Setelah pencabutan, publikasikan sidik jari token dan versi status. Resource server segera menghapus entri lokal; penarikan berkala (periodic pulls) atau pemeriksaan versi akan memperbaiki event yang terlewat. Wajibkan introspeksi daring (online) untuk tindakan berisiko tinggi jika pencabutan waktu nyata sebanding dengan latensi yang ditimbulkan.
Langkah 4: Menangani Kegagalan, Percobaan Ulang, dan Bukti Kepemilikan (Proof of Possession)
Gunakan backoff eksponensial dan circuit breaking pada batas waktu introspeksi agar resource server tidak membebani layanan otorisasi secara berlebihan. Selama pemadaman, pilih fail-closed atau penggunaan singkat cache positif yang belum kedaluwarsa berdasarkan risiko scope. Dengan DPoP, verifikasi juga bukti permintaan terhadap kunci publik yang terikat pada token, sehingga mengurangi risiko replay untuk bearer token yang disalin.
6. Contoh Jawaban Berkualitas Tinggi
Saya akan membagi sistem menjadi endpoint otorisasi, introspeksi, pencabutan, penyimpanan status, bus event pencabutan, dan SDK resource server. Penyimpanan status diberi kunci berdasarkan hash token dan menyimpan klien, scope, waktu penerbitan dan kedaluwarsa, ID grant, status pencabutan, serta versi. Introspeksi hanya mengembalikan field yang dibutuhkan resource server dan memerlukan autentikasi pemanggil.
>
SDK menyimpan cache scope biasa selama tiga puluh detik dan mengintrospeksi scope berisiko tinggi secara online. Pencabutan mendukung satu token maupun seluruh grant, kemudian mempublikasikan event berversi. SDK menghapus cache-nya saat menerima event tersebut, sementara tugas perbaikan berkala menangani event yang terlewat. Entri cache positif yang versinya tidak lagi cocok harus diintrospeksi ulang sebelum digunakan.
>
Jika terjadi batas waktu otorisasi, permintaan berisiko rendah dapat menggunakan cache positif yang belum kedaluwarsa sedangkan permintaan berisiko tinggi ditolak. Circuit breaking dan percobaan ulang dengan jitter mencegah kegagalan beruntun. Dengan DPoP, SDK memverifikasi bukti permintaan dan kunci yang terikat. Kueri, pencabutan, cache hit, dan kegagalan dikirim ke penyimpanan audit yang telah disunting agar penyebaran token yang dicuri dapat dilacak.
7. Pola Kegagalan Umum
- Menganggap validasi tanda tangan JWT lokal setara dengan pencabutan waktu nyata.
- Menyimpan cache hasil aktif untuk waktu yang lama tanpa event pencabutan atau pemeriksaan versi.
- Mengekspos introspeksi ke publik atau mengembalikan field pengguna yang tidak perlu.
- Menerapkan fail-open untuk setiap permintaan selama pemadaman otorisasi.
- Mencoba ulang tanpa batas waktu, circuit breaking, atau jitter sehingga menyebabkan lonjakan autentikasi (authentication stampede).
8. Pertanyaan Lanjutan dan Tanggapan
Pertanyaan Lanjutan 1: Mengapa cache negatif biasanya harus berdurasi lebih pendek?
Token mungkin baru saja diterbitkan, replika data mungkin belum sinkron, atau pencabutan masih dalam proses propagasi. Cache negatif yang singkat mencegah ketidakhadiran data sementara berubah menjadi jendela ketidakvalidan yang panjang.
Pertanyaan Lanjutan 2: Apakah pencabutan refresh token juga harus mencabut token akses?
Gunakan grant dan kebijakan keamanan. Jika refresh token dicuri, biasanya sisa token di bawah grant tersebut ikut dicabut dan biarkan resource server membatalkan validitas cache melalui versi atau event.
Pertanyaan Lanjutan 3: Bagaimana cara mencegah event pencabutan yang duplikat atau tidak berurutan?
Sertakan versi monotonik atau waktu pencabutan. Konsumen hanya menerima versi yang setidaknya sama baru dengan status lokal; event duplikat tetap bersifat idempoten, dan event lama tidak dapat mengembalikan status menjadi aktif.