1. Soalan dan Konteks
Pelbagai pelayan sumber API menerima token akses yang dikeluarkan oleh pelayan kebenaran. Mereka perlu mengetahui sama ada token adalah aktif, klien mana yang memilikinya, skop apa yang dimilikinya, dan bila ia tamat tempoh. Pasukan keselamatan juga memerlukan pembatalan pantas bagi token yang dicuri. Reka bentuk ini mesti mengimbangi pembatalan masa nyata, kependaman rendah, dan ketersediaan perkhidmatan kebenaran.
2. Perkara yang Dinilai oleh Penemu Duga
- Sama ada anda memahami semantik introspeksi RFC 7662 dan pembatalan RFC 7009.
- Sama ada cache, peristiwa pembatalan, dan versi menghalang hasil aktif yang lapuk daripada menyembunyikan pembatalan.
- Sama ada anda membezakan token legap (opaque), pengesahan JWT tempatan, dan bukti pemilikan (proof-of-possession) seperti DPoP.
- Sama ada dasar gangguan, percubaan semula, pengasingan penyewa, dan audit dinyatakan secara eksplisit.
3. Soalan Penjelasan Sebelum Anda Menjawab
- Adakah token tersebut merupakan token akses jangka pendek, token penyegar (refresh token), atau kedua-duanya?
- Adakah anda membatalkan satu token, geran (grant), sesi pengguna, atau keseluruhan klien?
- Berapakah kelewatan penyebaran pembatalan yang boleh diterima oleh pelayan sumber?
- Adakah anda perlu mengikat kunci klien atau kunci awam DPoP untuk mengelakkan main semula (replay) token pembawa yang disalin?
4. Rangka Jawapan 30 Saat
Gunakan titik akhir, punca kebenaran (source of truth), cache, penyebaran pembatalan, dan dasar kegagalan.
Pelayan kebenaran mendedahkan titik akhir introspeksi dan pembatalan yang dilindungi. Storan keadaan mengekalkan cincangan (hash) token, klien, skop, masa tamat tempoh, dan versi pembatalan. Pelayan sumber menyimpan cache hasil aktif untuk TTL yang singkat dan melanggan peristiwa pembatalan untuk memadamkan entri dengan serta-merta. Skop berisiko tinggi gagal tertutup (fail closed) semasa gangguan kebenaran; permintaan berisiko rendah boleh menggunakan cache positif yang belum tamat tempoh secara ringkas. Pertanyaan, pembatalan, dan kegagalan diaudit.
5. Analisis Terperinci Langkah demi Langkah
Langkah 1: Tentukan Keadaan Token dan Kebenaran Titik Akhir
Hanya pelayan sumber yang dipercayai boleh memanggil introspeksi. Kembalikan medan yang diperlukan seperti active, client_id, username, scope, exp, iat, dan sub tanpa mendedahkan data identiti yang tidak perlu. Titik akhir pembatalan mengesahkan pemanggil dan jenis tokennya, mematuhi RFC 7009 untuk pembatalan berulang, dan tidak mendedahkan sama ada token yang sudah tidak sah wujud sebelum ini.
Langkah 2: Reka Bentuk Storan Keadaan dan Indeks
Gunakan cap jari (fingerprint) atau cincangan token sebagai kunci. Simpan masa pengeluaran, tamat tempoh, ID geran, klien, skop, versi keadaan, dan sebab pembatalan. Indekskan ID geran untuk pembatalan pukal; elakkan teks biasa yang sensitif daripada log. Lakukan pembahagian (shard) mengikut penyewa atau cincangan supaya satu klien tidak menjadi partisyen panas (hot partition).
Langkah 3: Kendalikan Cache dan Penyebaran Pembatalan
Simpan cache hasil positif untuk TTL yang singkat; elakkan cache negatif yang panjang. Selepas pembatalan, terbitkan cap jari token dan versi keadaan. Pelayan sumber memadamkan entri tempatan dengan serta-merta; tarikan berkala atau semakan versi membaiki peristiwa yang terlepas. Wajibkan introspeksi dalam talian untuk tindakan berisiko tinggi apabila pembatalan masa nyata berbaloi dengan kependamannya.
Langkah 4: Kendalikan Kegagalan, Percubaan Semula, dan Bukti Pemilikan
Gunakan pengunduran eksponen (exponential backoff) dan pemutus litar (circuit breaking) pada had masa introspeksi supaya pelayan sumber tidak membebankan perkhidmatan kebenaran. Semasa gangguan, pilih fail-closed atau penggunaan ringkas cache positif yang belum tamat tempoh mengikut risiko skop. Dengan DPoP, sahkan juga bukti permintaan terhadap kunci awam yang terikat pada token, sekali gus mengurangkan risiko main semula untuk token pembawa yang disalin.
6. Contoh Jawapan Berkualiti Tinggi
Saya akan membahagikan sistem kepada titik akhir kebenaran, introspeksi, pembatalan, storan keadaan, bas peristiwa pembatalan, dan SDK pelayan sumber. Storan keadaan dikuncikan oleh cincangan token dan menyimpan klien, skop, masa pengeluaran dan tamat tempoh, ID geran, keadaan pembatalan, serta versi. Introspeksi hanya mengembalikan medan yang diperlukan oleh pelayan sumber dan memerlukan pengesahan pemanggil.
>
SDK menyimpan cache bagi skop biasa selama tiga puluh saat dan melakukan introspeksi bagi skop berisiko tinggi secara dalam talian. Pembatalan menyokong pembatalan satu token dan keseluruhan geran, kemudian menerbitkan peristiwa berversi. SDK memadamkan cachenya setelah menerima peristiwa tersebut, manakala tugas pembaikan berkala mengendalikan peristiwa yang terlepas. Entri cache positif yang versinya tidak lagi sepadan mesti diintrospeksi semula sebelum digunakan.
>
Sekiranya berlaku had masa kebenaran, permintaan berisiko rendah boleh menggunakan cache positif yang belum tamat tempoh manakala permintaan berisiko tinggi akan ditolak. Pemutus litar dan percubaan semula dengan variasi rawak (jitter) menghalang kegagalan berturutan. Dengan DPoP, SDK mengesahkan bukti permintaan dan kunci terikat. Pertanyaan, pembatalan, padanan cache, dan kegagalan dihantar ke storan audit yang telah disunting supaya penyebaran token yang dicuri dapat dikesan.
7. Mod Kegagalan Biasa
- Menganggap pengesahan tandatangan JWT tempatan sebagai pembatalan masa nyata.
- Menyimpan cache hasil aktif untuk masa yang lama tanpa peristiwa pembatalan atau semakan versi.
- Mendedahkan introspeksi secara terbuka atau mengembalikan medan pengguna yang tidak perlu.
- Memilih fail-open untuk setiap permintaan semasa gangguan perkhidmatan kebenaran.
- Mencuba semula tanpa had masa, pemutus litar, atau variasi rawak dan mencetuskan rempuhan pengesahan (authentication stampede).
8. Soalan Susulan dan Jawapan
Soalan Susulan 1: Mengapakah cache negatif biasanya perlu lebih pendek?
Token mungkin baru sahaja dikeluarkan, replika data mungkin lapuk, atau pembatalan mungkin masih dalam proses penyebaran. Cache negatif yang pendek mengelakkan ketiadaan sementara daripada menjadi tempoh ketidaksahan yang panjang.
Soalan Susulan 2: Patutkah pembatalan token penyegar turut membatalkan token akses?
Gunakan geran dan dasar keselamatan. Jika token penyegar dicuri, biasanya baki token di bawah geran tersebut akan dibatalkan dan biarkan pelayan sumber membatalkan cache melalui versi atau peristiwa.
Soalan Susulan 3: Bagaimanakah anda menghalang peristiwa pembatalan yang pendua atau tidak mengikut urutan?
Sertakan versi monotonik atau masa pembatalan. Pengguna hanya menerima versi yang sekurang-kurangnya sama baharu dengan keadaan tempatan; peristiwa pendua kekal idempoten, dan peristiwa lama tidak boleh memulihkan keadaan yang aktif.