Temu Duga Backend: Bagaimana Anda Memutarkan Kunci Menandatangani JWT Tanpa Menyebabkan Gangguan Pengesahan?

Prompt dan Konteks Berkenaan

Perkhidmatan pengesahan menandatangani token akses dengan RS256. Token boleh diterima paling lama selama 15 minit, dengan 1 minit pencongan jam (clock skew). Dua ratus perkhidmatan backend membaca jwks_uri yang tetap daripada dokumen OpenID Discovery pengeluar, menyimpan cache JWKS selama 10 minit, dan mengesahkan token secara setempat.

Reka bentuk pemutaran kunci menandatangani yang tidak menghasilkan gelombang respons 401 untuk permintaan yang sah. Liputi kes-kes ini:

• token lama dan baharu tiba semasa pemutaran normal;
• pengepala token mengandungi kid yang tiada dalam cache setempat;
• banyak nilai kid rawak cuba menghasilkan ribut penyegaran JWKS;
• titik akhir JWKS tamat masa atau gagal semasa pemutaran;
• kunci peribadi semasa mungkin terjejas (compromised) dan memerlukan tindakan kecemasan;
• pengendali mesti membuktikan setiap pengesah (verifier) menerima kunci baharu sebelum melupuskan kunci lama.

Jangka hayat 15 minit, cache 10 minit, pencongan jam 1 minit, dan 200 perkhidmatan ialah kekangan senario, bukan cadangan sejagat. Kemahiran teras ialah reka bentuk protokol pengesahan backend, ketekalan cache, semantik kegagalan, dan operasi keselamatan, jadi kategorinya ialah backend.

Perkara yang Dinilai oleh Penemu Duga

Pertama, bolehkah calon menyatakan urutan yang selamat: terbitkan kunci awam baharu, biarkan pengesah memerhatikannya, mula menandatangani dengan kunci peribadi baharu, tunggu sehingga token lama tamat tempoh, dan hanya selepas itu buang kunci awam lama? Menukar penandatangan terlebih dahulu menjamin bahawa perkhidmatan dengan cache JWKS lama akan menolak token baharu.

Kedua, adakah mereka memahami bahawa JWKS ialah set kunci awam? RFC 7517 mentakrifkan tatasusunan keys, dan kid hanya memilih kunci daripada set yang dipercayai. Kunci peribadi tidak boleh sama sekali diterbitkan dalam JWKS. kid juga bukan bukti kepercayaan; ia mesti terikat kepada pengeluar yang dipercayai, algoritma yang dipinkan, dan pengesahan tandatangan yang berjaya.

Ketiga, bolehkah mereka mengimbangi antara caching dan keselamatan? Mengambil JWKS pada setiap permintaan membebankan pengeluar, manakala menyimpan cache selama-lamanya melewatkan penerimaan kunci baharu dan pelupusan kunci lama. kid yang tidak diketahui boleh mencetuskan satu penyegaran terkawal, tetapi penyegaran serentak mesti digabungkan (coalesced), dihadkan kadarnya (rate-limited), dan diikuti dengan cache negatif singkat apabila pengecam disahkan tiada.

Keempat, adakah mereka memisahkan pemutaran yang dirancang daripada kompromi kunci peribadi? Pemutaran yang dirancang bertindih kunci awam lama dan baharu untuk ketersediaan. Semasa kompromi berlaku, mengekalkan kepercayaan pada kunci lama membolehkan penyerang mencipta token. Laluan kecemasan memerlukan pembatalan cache eksplisit, kawalan pembatalan, dan keutamaan keselamatan yang lebih kukuh.

Kelima, adakah mereka memperluas pemeriksaan tandatangan kepada pengesahan lengkap? Pengesah mengepin algoritma yang dibenarkan, kemudian mengesahkan tandatangan, iss, aud, exp, dan nbf. Ia tidak mengikut jku yang tidak dipercayai atau URL kunci sewenang-wenangnya daripada token, yang boleh membolehkan kekeliruan algoritma atau SSRF.

Soalan untuk Dijelaskan Sebelum Menjawab

• Berapakah masa penerimaan token maksimum? Gunakan jangka hayat setiap token lama yang masih boleh diterima, bukan sekadar TTL nominal yang dikonfigurasikan, dan sertakan pencongan jam.
• Berapakah keusangan (staleness) JWKS maksimum? Pelayar, CDN, proksi, dan cache dalam-proses masing-masing boleh menambah lapisan; pemutaran memerlukan batas atas yang sebenar.
• Bolehkah semua pengesah disegarkan secara proaktif? Tolakan konfigurasi, pengakuan versi, atau probe kenari boleh menggantikan tindakan menunggu tempoh luput semula jadi semata-mata.
• Apakah yang berlaku apabila JWKS tidak tersedia? Tentukan sama ada kunci yang diketahui boleh menggunakan cache basi terikat (bounded stale cache) dan sama ada kunci yang tidak diketahui gagal-tutup (fails closed).
• Adakah token yang telah dikeluarkan mesti dibatalkan serta-merta? JWT serba lengkap tidak boleh menyokong pembatalan khusus setiap token melalui pemutaran sahaja; senarai penafian (denylist), versi token, atau introspeksi mungkin diperlukan.
• Siapakah yang mengawal pengeluar dan pengesah? Satu organisasi boleh mengumpul pengakuan penyegaran; pengesah pihak ketiga biasanya bergantung pada tetingkap keserasian yang didokumentasikan.
• Di manakah kunci peribadi disimpan? Jana dan gunakannya dalam KMS, HSM, atau perkhidmatan menandatangani terhad; hanya bahan awam diletakkan pada satah penerbitan.
• Apakah maksud kejayaan? Pemutaran yang dirancang memastikan token lama dan baharu yang sah terus berfungsi. Pemutaran kecemasan mungkin menerima pengesahan semula terkawal untuk menghentikan kepercayaan terhadap kunci yang terjejas dengan cepat.

Rangka Kerja Jawapan 30 Saat

\"Saya membahagikan pemutaran kepada fasa terbit, panaskan (warm), tukar, bertindih, dan lupuskan. Saya menjana kunci dengan kid baharu, kemudian menerbitkan kedua-dua kunci awam baharu dan lama dalam JWKS. Saya menunggu tetingkap cache maksimum 10 minit, atau menyegarkan secara proaktif kesemua 200 pengesah dan mengumpul versi JWKS baharu mereka. Hanya selepas kunci awam baharu boleh disahkan, barulah pengeluar mula menandatangani dengan kunci peribadi baharu.

Saya mengekalkan kunci awam lama sehingga 15 minit selepas token lama terakhir dikeluarkan, ditambah 1 minit pencongan jam. Pengesah memilih kid hanya dalam set pengeluar yang dipercayai, mengepin RS256, dan mengesahkan tandatangan, iss, aud, exp, dan nbf. kid yang tidak diketahui mencetuskan satu penyegaran tergabung dan dihadkan kadarnya; jika ia masih tiada, tolak. Semasa gangguan JWKS, kunci yang diketahui boleh menggunakan cache basi yang dihadkan secara eksplisit, manakala kunci yang tidak diketahui gagal-tutup.

Jika kunci peribadi terjejas, saya menghentikan pengeluaran kunci lama, menerbitkan dan beralih kepada kunci baharu, menyiarkan pembatalan cache, dan membatalkan token yang ditandatangani oleh kunci lama. Saya tidak menggunakan tetingkap pertindihan normal. Saya membuktikan penyelesaian melalui keputusan mengikut kid, usia cache, volum pengambilan JWKS, dan pemerhatian terakhir kid lama.\"

Perbincangan Mendalam Langkah Demi Langkah

Langkah 1: Pin punca kepercayaan dan varian pengesahan

Pengesah bermula daripada pengeluar dipercayai yang dikonfigurasikan, membaca dokumen OpenID Discovery miliknya, dan menggunakan HTTPS jwks_uri daripada dokumen tersebut. Pengepala token kid hanya memilih kunci awam calon daripada JWKS yang dipercayai ini. Token tidak boleh mengalihkan pengesah melalui jku, dan aplikasi tidak boleh mencantumkan kid secara terus ke dalam carian fail, pangkalan data, atau URL.

Setiap pengesahan mengekalkan varian ini:

1. terima hanya RS256 yang dikonfigurasikan; token tidak boleh merundingkan algoritmanya;
2. memerlukan kid sepadan secara unik dengan satu kunci menandatangani dalam JWKS pengeluar yang dipercayai;
3. selepas pengesahan tandatangan, perlukan iss yang dijangkakan, aud API ini, exp, dan nbf;
4. tolak keseluruhan token jika mana-mana semakan gagal;
5. terbitkan bahan kunci awam sahaja manakala kunci peribadi kekal di dalam sempadan menandatangani yang dikawal.

Set kunci minimum semasa pemutaran boleh kelihatan seperti ini:

{
  "keys": [
    { "kty": "RSA", "use": "sig", "alg": "RS256", "kid": "2026-07-a", "n": "...", "e": "AQAB" },
    { "kty": "RSA", "use": "sig", "alg": "RS256", "kid": "2026-07-b", "n": "...", "e": "AQAB" }
  ]
}

Susunan tatasusunan bukanlah keutamaan; pengesah memilih kid yang tepat. Generasi baharu mendapat kid baharu yang tidak pernah diguna semula, kerana cache tidak dapat membezakan bahan kunci yang diubah yang tersembunyi di sebalik pengecam yang sama.

Langkah 2: Laksanakan pemutaran yang dirancang dengan terbit sebelum tandatangan

Modelkan pemutaran yang dirancang sebagai keadaan eksplisit:

GENERATED
  -> PUBLISHED(old + new)
  -> VERIFIER_READY
  -> SIGNING_WITH_NEW
  -> OLD_TOKEN_DRAINED
  -> OLD_KEY_RETIRED

Protokolnya ialah:

1. jana 2026-07-b dalam sistem kunci terkawal, tetapi jangan tandatangani dengannya lagi;
2. terbitkan JWKS yang mengandungi 2026-07-a dan 2026-07-b, dengan ETag baharu atau versi set;
3. tunggu tetingkap keusangan cache maksimum 10 minit, atau segarkan kesemua 200 pengesah dan kumpulkan pengakuan bahawa mereka mengenali kid baharu;
4. sahkan tuntutan tandatangan, pengeluar, audiens, dan masa dengan token kenari dalam setiap persekitaran;
5. hanya selepas pengesah menerima kunci awam baharu, mulakan menandatangani dengan 2026-07-b;
6. rekod T_last_old, iaitu masa pengeluaran token kunci lama yang terakhir;
7. tidak lebih awal daripada T_last_old + 15 minutes + 1 minute, dan selepas trafik kid lama sepadan dengan jangkaan, buang kunci awam lama daripada JWKS;
8. teruskan memantau trafik kid lama yang tidak normal, kemudian nyahdayakan dan musnahkan bahan peribadi lama.

\"Terbit sebelum tandatangan\" melindungi token baharu. \"Hentikan tandatangan lama, habiskan aliran token lama, kemudian buang\" melindungi token lama. Penyebaran cache mengawal pertukaran tandatangan paling awal; jangka hayat penerimaan token lama dan pencongan jam mengawal penyingkiran kunci awam paling awal.

Langkah 3: Kendalikan kid yang tidak diketahui dengan satu penyegaran terkawal

kid yang tidak diketahui mungkin merupakan generasi baharu yang sah atau hingar yang dibekalkan oleh penyerang. Pengesah tidak boleh menolak setiap kemunculan pertama dengan serta-merta, dan ia tidak boleh menukar setiap kemunculan menjadi trafik huluan tanpa had. Aliran yang sesuai ialah:

verify(token):
  header = parse_bounded_header(token)
  require header.alg == "RS256"
  key = trusted_cache.find(header.kid)
  if key is missing:
    refresh trusted_issuer_jwks once through single-flight
    key = trusted_cache.find(header.kid)
  if key is missing:
    short_negative_cache.add(header.kid)
    reject "unknown kid"
  verify signature and require iss, aud, exp, nbf

Kehilangan padanan (misses) serentak bagi satu pengeluar berkongsi penyegaran penerbangan tunggal (single-flight refresh). Penyegaran mempunyai tempoh bertenang (cooldown) global dan masa tamat. Selepas set baharu mengesahkan bahawa kid tiada, cache negatif singkat menghalang pengecam rawak berulang daripada sampai ke pengeluar. TTL negatif tidak boleh terlalu panjang sehingga menyekat pemutaran sebenar, dan pengesah mesti mengehadkan panjang dan format kid untuk menghalang serangan memori berkardinaliti tinggi.

Penyegaran hanya mengakses jwks_uri yang dikonfigurasikan, melalui TLS, dengan had saiz respons, sambungan, dan bacaan. Ia boleh menggunakan permintaan bersyarat ETag. Lokasi jku, x5u, atau lokasi serupa yang disediakan oleh penyerang tidak boleh sama sekali menggantikan punca kepercayaan.

Langkah 4: Tentukan sempadan ketersediaan semasa kegagalan JWKS

Permintaan biasa menggunakan cache setempat; titik akhir JWKS tidak berada dalam laluan segerak setiap permintaan pengesahan. Jika penyegaran gagal:

• kid padanan yang diketahui boleh diteruskan dalam tetingkap basi terikat yang telah ditetapkan;
• kid yang tidak diketahui mesti ditolak, tidak sekali-kali disahkan tanpa tandatangan atau terhadap kunci yang tidak berkaitan;
• selepas tetingkap basi terikat tamat tempoh, kegagalan untuk menyegar mencetuskan amaran dan mengikut dasar keselamatan, biasanya penolakan;
• pengeluar tidak boleh beralih kepada kunci menandatangani baharu apabila ia tidak dapat membuktikan bahawa pengesah mempunyai kunci awam baharu.

stale-if-error yang singkat menyerap gangguan satah kawalan tetapi juga melanjutkan kepercayaan setempat pada kunci yang dialih keluar daripada set semasa. Tempoh tersebut tergolong dalam model keselamatan dan mesti ditindih oleh pembatalan eksplisit semasa berlakunya kompromi. Ketersediaan tidak boleh bergantung pada kunci yang basi selama-lamanya.

Langkah 5: Gunakan laluan kecemasan berasingan untuk kompromi kunci peribadi

Kompromi mengubah objektif kepada menghentikan penerimaan token yang ditempa oleh penyerang secepat mungkin. Hentikan pengeluaran kunci lama, jana dan terbitkan kunci awam baharu, paksa pengesah untuk menyegar, tukar penandatangan, dan tandakan kunci lama sebagai dibatalkan. Jangan kekalkan pertindihan normal 16 minit semata-mata untuk pengalaman yang lancar.

Memadam kunci awam lama daripada JWKS pusat tidak mencukupi kerana pengesah boleh mengekalkan cache 10 minitnya. Gunakan siaran satah kawalan yang telah diuji, tolakan versi cache, mulakan semula perkhidmatan, atau saluran pembatalan lain. Jika pengesah pihak ketiga tidak dapat dihubungi, pengeluar dihadkan oleh batas atas cache mereka dan mesti menyatakan pendedahan itu secara eksplisit.

Pemutaran juga tidak menarik balik token serba lengkap yang telah dikeluarkan dengan tepat. Untuk pembatalan serta-merta, gunakan peraturan sementara mengikut kid lama atau had masa iat, pendekkan jangka hayat token akses, atau gunakan introspeksi/keadaan sesi untuk API berisiko tinggi. Tindak balas kecemasan mungkin memaksa pengguna untuk mengesahkan semula; itu adalah impak perniagaan yang boleh diterima apabila keselamatan diutamakan.

Langkah 6: Buktikan penyelesaian dengan versi, metrik, dan audit

Respons JWKS harus mendedahkan versi set atau ETag yang boleh diperhatikan. Pengesah melaporkan versi semasa, usia cache, hasil penyegaran, dan nilai kid yang diiktiraf. Pengeluar merekodkan kid menandatangani yang aktif, tanpa melog kandungan token atau bahan peribadi.

Metrik utama termasuk hasil pengesahan mengikut pengeluar, kid, dan ralat; kardinaliti kid yang tidak diketahui; kiraan pengambilan JWKS, kependaman, dan kadar kegagalan; penggabungan penerbangan tunggal (single-flight); usia cache; kejayaan kenari kunci baharu; dan penggunaan sah terakhir kid lama. Peningkatan ralat kunci tidak diketahui untuk kid baharu selepas pertukaran harus menghentikan atau mengundurkan (rollback) perubahan penandatanganan sebelum pengguna melaporkannya.

Rekod audit menjawab siapa yang menjana, menerbitkan, mengaktifkan, dan melupuskan setiap kunci; versi JWKS mana yang semasa; pengesah mana yang mengakui kesediaan; dan apakah masa pengeluaran lama terakhir yang mewajarkan pelupusan. Kelulusan berganda dan keistimewaan paling sedikit menjadikan operasi kitaran hayat kunci lebih selamat.

Langkah 7: Uji peralihan dan input musuh

Jangan uji hanya satu token sah yang statik. Liputi sekurang-kurangnya:

1. dengan hanya kunci awam lama diterbitkan, token lama lulus dan token kunci baharu gagal;
2. semasa pertindihan, kedua-dua generasi token lulus dan pemeriksaan berulang tidak mengambil semula JWKS;
3. dengan hanya kunci lama dicache, kid baharu lulus selepas tepat satu penyegaran terkawal;
4. banyak nilai kid tidak diketahui yang serupa atau rawak menyebabkan penyegaran terikat dan ditolak;
5. masa tamat JWKS, 500, respons bersaiz terlalu besar, dan JSON tidak sah mengekalkan dasar kunci yang diketahui manakala kunci yang tidak diketahui gagal;
6. algoritma salah, iss, aud, token tamat tempoh, dan token belum sah semuanya gagal;
7. jku yang dibekalkan oleh penyerang tidak menyebabkan pengesah menghubungi lokasi berbeza;
8. selepas penyingkiran kunci lama, proses baharu menolak token lama, manakala cache lama menerima hanya dalam tetingkap yang dinyatakan;
9. latih tubi kompromi membatalkan kid lama merentasi setiap pengesah yang dikawal;
10. get menandatangani menghalang pengaktifan kunci baharu selagi pengesah belum bersedia.

Penerimaan memeriksa kedua-dua keputusan kebenaran dan kiraan permintaan JWKS. Token yang lulus manakala setiap permintaan mencapai pengeluar bukanlah pelaksanaan yang betul. Begitu juga halnya dengan volum pengambilan normal tetapi token baharu yang sah ditolak.

Contoh Jawapan Berkualiti Tinggi

\"Saya mentakrifkan kid sebagai pemilih dalam JWKS pengeluar yang dipercayai, bukan sebagai punca kepercayaan. Setiap pengesah hanya menerima RS256 yang dikonfigurasikan, memperoleh kunci awam daripada Discovery jwks_uri yang tetap, memilih mengikut kid, dan mengesahkan tandatangan, iss, aud, exp, dan nbf. JWKS mengandungi kunci awam sahaja; kunci peribadi kekal dalam sempadan menandatangani KMS atau HSM.

Untuk pemutaran yang dirancang, saya menjana kunci dengan kid baharu, menerbitkan kedua-dua kunci awam lama dan baharu, dan mengemas kini ETag. Saya kemudian menunggu tetingkap cache maksimum senario iaitu 10 minit atau secara proaktif menyegarkan kesemua 200 pengesah dan mengumpul kesediaan. Token kenari membuktikan bahawa kunci baharu berfungsi sebelum penandatangan bertukar.

Saya merekodkan masa pengeluaran token lama yang terakhir. Kunci awam lama kekal selama sekurang-kurangnya jangka hayat penerimaan 15 minit ditambah 1 minit pencongan jam, dan saya mengalih keluarnya hanya selepas trafik kid lama habis mengalir. Kedua-dua get peralihan adalah eksplisit: jangan tandatangani token baharu sehingga kunci awam baharu telah disebarkan, dan jangan buang kunci awam lama sehingga token lama menjadi tidak sah.

Apabila kehilangan cache (cache miss) berlaku, setiap pengeluar mendapat satu penyegaran penerbangan tunggal dengan masa tamat, tempoh bertenang, dan ETag. Jika kunci kekal tiada, tolak dan simpan dalam cache negatif secara singkat. Nilai kid rawak tidak boleh menguat menjadi limpahan ke huluan. Semasa kegagalan sementara JWKS, kunci yang diketahui boleh diteruskan hanya dalam tetingkap basi terikat yang dinyatakan, manakala kunci yang tidak diketahui sentiasa gagal-tutup.

Jika kunci peribadi lama terjejas, saya menghentikan penandatanganan lama, menerbitkan dan bertukar kepada kunci baharu, menyiarkan pembatalan cache, dan membatalkan token dalam julat kid lama atau iat lama. Saya tidak mengekalkan pertindihan normal kerana penyerang mungkin sedang menandatangani. Akhir sekali, saya membuktikan penyelesaian dengan versi JWKS, usia cache, ralat pengesahan mengikut kid, kenari kunci baharu, dan pemerhatian kid lama yang terakhir, serta saya kerap menguji fasa peralihan dan kegagalan pengeluar.\"

Kesilapan Biasa

• Menukar penandatangan sebelum menerbitkan kunci awam → perkhidmatan dengan JWKS basi menolak token baharu → terbitkan, buktikan penyebaran, kemudian mulakan penandatanganan baharu.
• Menerbitkan kunci baharu sahaja → token lama yang sah gagal serta-merta → terbitkan kedua-dua generasi semasa tetingkap penerimaan.
• Menunggu tempoh sewenang-wenangnya → ia mungkin lebih pendek daripada jangka hayat cache atau token sebenar → terbitkan get daripada keusangan maksimum, pengeluaran lama terakhir, jangka hayat token, dan pencongan jam.
• Memuat turun JWKS untuk setiap permintaan → kegagalan pengeluar merosakkan semua pengesahan dan menggandakan beban → gunakan caching setempat, penyegaran bersyarat, dan dasar basi terikat.
• Menyegar untuk setiap kid yang tidak diketahui → pengecam rawak menghasilkan ribut penyegaran → gunakan penerbangan tunggal (single-flight), had kadar, caching negatif, dan batasan input.
• Mencuba setiap kunci untuk kid yang tidak diketahui → pemilihan kunci menjadi kabur dan meluaskan permukaan serangan → segarkan sekali, kemudian tolak tanpa padanan yang tepat.
• Mempercayai alg atau jku daripada token → kekeliruan algoritma atau SSRF mungkin menyusul → pin algoritma dan lokasi JWKS dalam konfigurasi pengesah.
• Memeriksa tandatangan sahaja → token untuk pengeluar, audiens, atau masa lain boleh diterima → sahkan juga iss, aud, exp, dan nbf.
• Menggunakan semula kid dengan bahan kunci baharu → cache tidak dapat mengetahui bahawa satu pengecam telah berubah → tetapkan pengecam baharu untuk setiap generasi kunci.
• Menganggap pemadaman JWKS pusat sebagai pembatalan serta-merta → pengesah mungkin masih memegang cache lama → sediakan pembatalan cache eksplisit dan pembatalan token.
• Mengekalkan pertindihan normal selepas kompromi → penyerang boleh mencipta token sepanjang tetingkap tersebut → gunakan laluan kecemasan dan terima pengesahan semula yang diperlukan.

Soalan Susulan dan Respons

Susulan 1: Berapa lamakah sebenarnya kunci awam lama patut dikekalkan?

Bermula pada masa pengeluaran token kunci lama yang terakhir, simpan selama sekurang-kurangnya \"jangka hayat penerimaan maksimum + pencongan jam.\" Dalam senario ini, nilainya ialah 15 + 1 = 16 minit. Tambah kelewatan giliran (queue delay), pengeluaran luar talian, atau mana-mana tetingkap penerimaan tersirat yang lebih panjang jika ia wujud. Perhatikan trafik kid lama sebelum pembuangan supaya konfigurasi dan realiti masa jalanan bersesuaian.

Susulan 2: Mengapakah tidak mengembalikan 401 serta-merta untuk kid yang tidak diketahui?

Selepas pemutaran yang sah, token baharu boleh tiba sebelum penyegaran cache semula jadi bagi proses ini berlaku. Satu penyegaran terkawal merapatkan jurang tersebut. Ia mesti digabungkan, dihadkan kadarnya, dan dihadkan kepada URL yang dipercayai; tolak hanya apabila set terkini masih tidak mempunyai kid tersebut, sekali gus mengimbangi keserasian dengan rintangan penguatan.

Susulan 3: Patutkah pengesahan gagal-buka (fail open) apabila JWKS tergendala?

Jangan sekali-kali melangkau pengesahan tandatangan. Kunci padanan yang sudah dipercayai dalam cache boleh melengkapkan pengesahan penuh dalam tetingkap basi terikat yang eksplisit. Tolak kunci yang tidak diketahui atau permintaan selepas tetingkap tersebut. Ini menghalang gangguan satah kawalan yang singkat daripada menjejaskan setiap permintaan satah data di samping mengekalkan had kepercayaan yang boleh diukur.

Susulan 4: Mengapakah token lama boleh berfungsi selepas memadam kunci yang terjejas?

Pengesah mungkin masih mempunyai cache lama 10 minit, dan JWT serba lengkap tidak merujuk kepada pihak berkuasa pusat. Laluan kecemasan mesti membatalkan cache secara proaktif dan menggunakan peraturan penolakan sementara mengikut kid lama, masa pengeluaran, atau versi token. Sistem berisiko tinggi boleh menggunakan introspeksi atau sesi pihak pelayan untuk pembatalan yang lebih pantas.

Susulan 5: Bagaimana anda mengelakkan ribut penyegaran semasa pemutaran?

Prapenerbitan membolehkan kebanyakan proses memperoleh kunci semasa penyegaran semula jadi, dan penyegaran proaktif boleh dijarakkan dengan jitter. Untuk ketiadaan padanan sebenar, gunakan satu penerbangan tunggal bagi setiap pengeluar, ditambah dengan tempoh bertenang, ETag, masa tamat, dan caching negatif yang singkat. Pantau volum permintaan JWKS dan kardinaliti kid yang tidak diketahui; hadkan kadar anomali daripada mencuba semula dengan lebih kerap.

Susulan 6: Bagaimanakah get menandatangani boleh diautomasikan?

Tetapkan versi pada setiap JWKS. Pengesah melaporkan versi yang dimuatkan dan kid yang dikenali secara berkala. Pengawal keluaran memerlukan tahap kesediaan sasaran dan token kenari yang berjaya pada laluan kritikal sebelum mengaktifkan kunci peribadi. Sebarang peningkatan dalam kegagalan pengesahan kid baharu menjeda atau mengundurkan penandatanganan; membiarkan kunci awam baharu diterbitkan tidak memudaratkan token lama.

Susulan 7: Bagaimana jika pengesah pihak ketiga tidak dapat mengakui kesediaan?

Terbitkan kontrak pertindihan yang stabil: dedahkan kunci awam baharu sekurang-kurangnya satu tempoh cache maksimum lebih awal, kekalkan kunci lama sehingga semua token lama tamat tempoh, dan hantar pengepala caching yang sesuai. Pengeluar tidak boleh memaksa pihak ketiga untuk menyegar, jadi tetingkap keserasian, notis perubahan, dan pemeriksaan kenari menggantikan pengakuan dalaman. Kompromi kecemasan masih boleh meninggalkan tetingkap pendedahan yang tidak dapat dielakkan.