Wawancara Backend: Bagaimana Cara Merotasi Kunci Penandatanganan JWT Tanpa Menyebabkan Gangguan Autentikasi?

Perintah dan Konteks yang Berlaku

Sebuah layanan autentikasi menandatangani token akses dengan RS256. Sebuah token dapat diterima paling lama 15 menit, dengan 1 menit clock skew. Dua ratus layanan backend membaca jwks_uri tetap dari dokumen OpenID Discovery milik issuer, menyimpan JWKS dalam cache selama 10 menit, dan memverifikasi token secara lokal.

Rancang rotasi signing key yang tidak menghasilkan gelombang respons 401 untuk permintaan yang valid. Cakup kasus-kasus berikut:

• token lama dan baru tiba selama rotasi normal;
• header token berisi kid yang tidak ada di cache lokal;
• banyak nilai kid acak mencoba menciptakan badai penyegaran (refresh storm) JWKS;
• endpoint JWKS mengalami timeout atau gagal selama rotasi;
• private key saat ini mungkin telah terkompromi dan memerlukan tindakan darurat;
• operator harus membuktikan bahwa setiap verifier menerima kunci baru sebelum mempensiunkan kunci lama.

Masa berlaku 15 menit, cache 10 menit, skew 1 menit, dan 200 layanan adalah batasan skenario, bukan rekomendasi universal. Keterampilan intinya adalah perancangan protokol autentikasi backend, konsistensi cache, semantik kegagalan, dan operasi keamanan, sehingga kategorinya adalah backend.

Apa yang Dievaluasi Pewawancara

Pertama, dapatkah kandidat menyatakan urutan yang aman: publikasikan public key baru, biarkan verifier mengamatinya, mulai menandatangani dengan private key baru, tunggu hingga token lama kedaluwarsa, dan baru setelah itu menghapus public key lama? Mengalihkan signer terlebih dahulu menjamin bahwa layanan dengan cache JWKS lama akan menolak token baru.

Kedua, apakah mereka memahami bahwa JWKS adalah sebuah set public key? RFC 7517 mendefinisikan array keys, dan kid hanya memilih sebuah kunci dari set yang tepercaya. Private key tidak boleh dipublikasikan di JWKS. Sebuah kid juga bukan bukti kepercayaan; ia harus terikat pada issuer yang tepercaya, algoritma yang di-pin, dan verifikasi tanda tangan yang berhasil.

Ketiga, dapatkah mereka menyeimbangkan caching dan keamanan? Mengambil JWKS pada setiap permintaan membebani issuer secara berlebihan, sedangkan menyimpan cache selamanya menunda penerimaan kunci baru dan penghentian kunci lama. kid yang tidak dikenal dapat memicu satu penyegaran terkontrol, tetapi penyegaran konkuren harus digabungkan (coalesced), dibatasi kecepatannya (rate-limited), dan diikuti oleh negative cache singkat ketika pengidentifikasi dipastikan tidak ada.

Keempat, apakah mereka memisahkan rotasi terencana dari kompromi private key? Rotasi terencana menumpangkan (overlap) public key lama dan baru demi ketersediaan. Selama kompromi, mempertahankan kepercayaan pada kunci lama memungkinkan penyerang mencetak token. Jalur darurat memerlukan pembatalan cache eksplisit, kontrol pencabutan, dan prioritas keamanan yang lebih kuat.

Kelima, apakah mereka memperluas pemeriksaan tanda tangan menjadi validasi lengkap? Verifier mem-pin algoritma yang diizinkan, lalu memvalidasi tanda tangan, iss, aud, exp, dan nbf. Verifier tidak mengikuti jku yang tidak tepercaya atau URL kunci arbitrer dari token, yang dapat memungkinkan kebingungan algoritma atau SSRF.

Pertanyaan untuk Diklarifikasi Sebelum Menjawab

• Berapa waktu penerimaan token maksimum? Gunakan masa berlaku setiap token lama yang masih dapat diterima, tidak hanya TTL nominal yang dikonfigurasi, dan sertakan clock skew.
• Berapa batas keusangan (staleness) maksimum JWKS? Browser, CDN, proxy, dan cache dalam proses masing-masing dapat menambahkan lapisan; rotasi membutuhkan batas atas yang sebenarnya.
• Bisakah semua verifier disegarkan secara proaktif? Push konfigurasi, pengakuan versi, atau canary probe dapat menggantikan sekadar menunggu kedaluwarsa alami.
• Apa yang terjadi saat JWKS tidak tersedia? Tentukan apakah kunci yang dikenal dapat menggunakan cache basi terbatas (bounded stale cache) dan apakah kunci yang tidak dikenal bersifat fail-closed.
• Haruskah token yang sudah diterbitkan segera dicabut? JWT mandiri (self-contained) tidak dapat mendukung pencabutan per-token yang presisi hanya melalui rotasi; denylist, versi token, atau introspeksi mungkin diperlukan.
• Siapa yang mengendalikan issuer dan verifier? Satu organisasi dapat mengumpulkan pengakuan penyegaran; verifier pihak ketiga biasanya bergantung pada jendela kompatibilitas yang terdokumentasi.
• Di mana private key disimpan? Buat dan gunakan private key di KMS, HSM, atau layanan penandatanganan terbatas; hanya materi publik yang berada di bidang publikasi (publication plane).
• Apa arti dari keberhasilan? Rotasi terencana membuat token lama dan baru yang valid tetap berfungsi. Rotasi darurat dapat menerima reautentikasi terkontrol untuk segera berhenti memercayai kunci yang terkompromi.

Kerangka Jawaban 30 Detik

"Saya membagi rotasi menjadi publikasi, pemanasan (warm), pengalihan (switch), tumpang tindih (overlap), dan pemensiunan (retire). Saya menghasilkan kunci dengan kid baru, lalu memublikasikan public key baru dan lama di JWKS. Saya menunggu jendela cache maksimum 10 menit, atau secara proaktif menyegarkan seluruh 200 verifier dan mengumpulkan versi JWKS baru mereka. Hanya setelah public key baru dapat diverifikasi, issuer mulai menandatangani dengan private key baru.

Saya mempertahankan public key lama hingga 15 menit setelah token lama terakhir diterbitkan, ditambah 1 menit clock skew. Verifier memilih kid hanya dalam set issuer tepercaya, mem-pin RS256, dan memvalidasi tanda tangan, iss, aud, exp, serta nbf. kid yang tidak dikenal memicu satu penyegaran gabungan yang dibatasi kecepatannya; jika masih tidak ada, tolak. Selama pemadaman JWKS, kunci yang dikenal dapat menggunakan cache basi yang dibatasi secara eksplisit, sementara kunci yang tidak dikenal mengalami fail-closed.

Jika private key terkompromi, saya menghentikan penerbitan dengan kunci lama, memublikasikan dan beralih ke kunci baru, menyiarkan pembatalan cache, dan mencabut token yang ditandatangani oleh kunci lama. Saya tidak menggunakan jendela tumpang tindih normal. Saya membuktikan penyelesaian melalui hasil berdasarkan kid, usia cache, volume pengambilan JWKS, dan pengamatan terakhir dari kid lama."

Pembahasan Mendalam Langkah demi Langkah

Langkah 1: Pin trust root dan invarian verifikasi

Verifier memulai dari issuer tepercaya yang dikonfigurasi, membaca dokumen OpenID Discovery-nya, dan menggunakan HTTPS jwks_uri dari dokumen tersebut. kid pada header token hanya memilih kandidat public key dari JWKS tepercaya ini. Token tidak dapat mengarahkan ulang verifier melalui jku, dan aplikasi tidak boleh menggabungkan kid secara langsung ke dalam pencarian file, database, atau URL.

Setiap verifikasi mempertahankan invarian ini:

1. terima hanya RS256 yang dikonfigurasi; token tidak dapat menegosiasikan algoritmanya;
2. mewajibkan kid cocok secara unik dengan satu signing key di JWKS milik issuer tepercaya;
3. setelah verifikasi tanda tangan, wajibkan iss yang diharapkan, aud API ini, exp, dan nbf;
4. tolak seluruh token jika ada pemeriksaan yang gagal;
5. publikasikan hanya materi public key sementara private key tetap berada di dalam batas penandatanganan yang terkontrol.

Set kunci minimal selama rotasi dapat terlihat 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" }
  ]
}

Urutan array bukanlah preferensi; verifier memilih kid yang tepat. Generasi baru mendapatkan kid baru yang tidak pernah digunakan kembali, karena cache tidak dapat membedakan materi kunci yang diubah yang tersembunyi di balik pengidentifikasi yang sama.

Langkah 2: Jalankan rotasi terencana dengan publish before sign

Modelkan rotasi terencana sebagai status eksplisit:

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

Protokolnya adalah:

1. hasilkan 2026-07-b dalam sistem kunci yang terkontrol, tetapi jangan menandatangani dengannya terlebih dahulu;
2. publikasikan JWKS yang berisi 2026-07-a dan 2026-07-b, dengan ETag atau versi set baru;
3. tunggu jendela keusangan cache maksimum 10 menit, atau segarkan seluruh 200 verifier dan kumpulkan pengakuan bahwa mereka mengenali kid baru;
4. verifikasi klaim tanda tangan, issuer, audience, dan waktu dengan token canary di setiap lingkungan;
5. hanya setelah verifier menerima public key baru, mulai menandatangani dengan 2026-07-b;
6. catat T_last_old, waktu penerbitan token kunci lama terakhir;
7. tidak lebih awal dari T_last_old + 15 minutes + 1 minute, dan setelah lalu lintas kid lama sesuai ekspektasi, hapus public key lama dari JWKS;
8. terus pantau anomali lalu lintas kid lama, lalu nonaktifkan dan hancurkan materi privat lama.

"Publish before sign" melindungi token baru. "Hentikan penandatanganan lama, habiskan token lama, lalu hapus" melindungi token lama. Propagasi cache mengontrol pengalihan penandatanganan paling awal; masa berlaku penerimaan token lama dan clock skew mengontrol penghapusan public key paling awal.

Langkah 3: Tangani kid yang tidak dikenal dengan satu penyegaran terkontrol

kid yang tidak dikenal mungkin merupakan generasi baru yang sah atau derau (noise) yang diberikan penyerang. Verifier tidak dapat langsung menolak setiap kemunculan pertama, dan tidak dapat mengubah setiap kemunculan menjadi lalu lintas upstream tanpa batas. Alur yang cocok adalah:

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

Miss yang terjadi secara konkuren untuk satu issuer berbagi satu penyegaran single-flight. Penyegaran memiliki cooldown dan timeout global. Setelah set baru mengonfirmasi bahwa kid tidak ada, negative cache singkat mencegah pengidentifikasi acak berulang mencapai issuer. TTL negatif tidak boleh terlalu panjang hingga memblokir rotasi nyata, dan verifier harus membatasi panjang dan format kid untuk mencegah serangan memori ber-kardinalitas tinggi.

Penyegaran hanya mengakses jwks_uri yang dikonfigurasi, melalui TLS, dengan batas ukuran respons, koneksi, dan pembacaan. Ini dapat menggunakan permintaan kondisional ETag. jku, x5u, atau lokasi serupa yang disediakan penyerang tidak pernah menggantikan trust root.

Langkah 4: Tentukan batas ketersediaan selama kegagalan JWKS

Permintaan normal menggunakan cache lokal; endpoint JWKS tidak berada di jalur sinkron setiap permintaan autentikasi. Jika penyegaran gagal:

• kid dikenal yang cocok dapat berlanjut dalam batas jendela basi (bounded stale window) yang telah ditentukan sebelumnya;
• kid yang tidak dikenal harus ditolak, tidak pernah diverifikasi tanpa tanda tangan atau terhadap kunci yang tidak terkait;
• setelah batas jendela basi berakhir, kegagalan penyegaran memunculkan peringatan dan mengikuti kebijakan keamanan, biasanya penolakan;
• issuer tidak boleh beralih ke signing key baru jika tidak dapat membuktikan bahwa verifier telah memiliki public key baru.

stale-if-error singkat dapat meredam gangguan control-plane sementara tetapi juga memperpanjang kepercayaan lokal pada kunci yang telah dihapus dari set saat ini. Durasi tersebut termasuk dalam model keamanan dan harus digantikan oleh pembatalan eksplisit selama kompromi. Ketersediaan tidak boleh bergantung pada kunci basi tanpa batas.

Langkah 5: Gunakan jalur darurat terpisah untuk kompromi private key

Kompromi mengubah tujuan menjadi menghentikan penerimaan token yang dicetak penyerang secepat mungkin. Hentikan penerbitan dengan kunci lama, buat dan publikasikan public key baru, paksa verifier untuk menyegarkan cache, alihkan signer, dan tandai kunci lama telah dicabut. Jangan mempertahankan tumpang tindih 16 menit normal hanya demi pengalaman yang mulus.

Menghapus public key lama dari JWKS pusat tidak cukup karena verifier dapat mempertahankan cache 10 menitnya. Gunakan siaran control-plane yang telah diuji, push versi cache, restart layanan, atau saluran pembatalan lainnya. Jika verifier pihak ketiga tidak dapat dihubungi, issuer dibatasi oleh batas atas cache mereka dan harus menyatakan paparan tersebut secara eksplisit.

Rotasi juga tidak menarik kembali token mandiri yang sudah diterbitkan secara presisi. Untuk pencabutan segera, terapkan aturan sementara berdasarkan kid lama atau batas waktu iat, perpendek masa berlaku access token, atau gunakan status introspeksi/sesi untuk API berisiko tinggi. Tanggap darurat dapat memaksa pengguna untuk mengautentikasi ulang; itu adalah dampak bisnis yang dapat diterima ketika keamanan menjadi prioritas.

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

Respons JWKS harus mengekspos versi set atau ETag yang dapat diamati. Verifier melaporkan versi saat ini, usia cache, hasil penyegaran, dan nilai kid yang dikenali. Issuer mencatat kid penandatanganan aktifnya, tanpa mencatat body token atau materi privat.

Metrik utama mencakup hasil verifikasi berdasarkan issuer, kid, dan error; kardinalitas kid yang tidak dikenal; jumlah pengambilan JWKS, latensi, dan tingkat kegagalan; penggabungan single-flight; usia cache; keberhasilan canary kunci baru; dan penggunaan sah terakhir dari kid lama. Peningkatan error kunci tidak dikenal untuk kid baru setelah pengalihan harus menghentikan sementara atau me-rollback perubahan penandatanganan sebelum pengguna melaporkannya.

Catatan audit menjawab siapa yang membuat, memublikasikan, mengaktifkan, dan mempensiunkan setiap kunci; versi JWKS mana yang berlaku; verifier mana yang mengakui kesiapan; dan waktu penerbitan lama terakhir apa yang membenarkan pemensiunan. Persetujuan ganda (dual approval) dan hak istimewa paling rendah (least privilege) membuat operasi siklus hidup kunci lebih aman.

Langkah 7: Uji transisi dan input yang merugikan (adversarial)

Jangan hanya menguji satu token valid statis. Cakup setidaknya:

1. hanya dengan public key lama yang dipublikasikan, token lama lolos dan token kunci baru gagal;
2. selama tumpang tindih, kedua generasi token lolos dan pemeriksaan berulang tidak mengambil ulang JWKS;
3. hanya dengan kunci lama yang di-cache, kid baru lolos setelah tepat satu penyegaran terkontrol;
4. banyak nilai kid tidak dikenal yang identik atau acak menyebabkan penyegaran terbatas dan ditolak;
5. timeout JWKS, 500, respons terlalu besar, dan JSON tidak valid mempertahankan kebijakan kunci yang dikenal sementara kunci yang tidak dikenal gagal;
6. algoritma yang salah, iss, aud, token kedaluwarsa, dan token yang belum valid semuanya gagal;
7. jku yang disediakan penyerang tidak membuat verifier menghubungi lokasi yang berbeda;
8. setelah penghapusan kunci lama, proses baru menolak token lama, sementara cache lama hanya menerima dalam batas jendelanya;
9. simulasi kompromi membatalkan kid lama di setiap verifier yang terkontrol;
10. gerbang penandatanganan (signing gate) mencegah aktivasi kunci baru saat verifier belum siap.

Penerimaan memeriksa hasil otorisasi dan jumlah permintaan JWKS. Token yang lolos sementara setiap permintaan mencapai issuer bukanlah implementasi yang benar. Begitu pula volume pengambilan normal dengan token baru yang valid ditolak.

Contoh Jawaban Berkualitas Tinggi

"Saya mendefinisikan kid sebagai pemilih dalam JWKS milik issuer tepercaya, bukan sebagai sumber kepercayaan. Setiap verifier hanya menerima RS256 yang dikonfigurasi, mendapatkan public key dari Discovery jwks_uri tetap, memilih berdasarkan kid, dan memvalidasi tanda tangan, iss, aud, exp, serta nbf. JWKS hanya berisi public key; private key tetap berada di dalam batas penandatanganan KMS atau HSM.

Untuk rotasi terencana, saya membuat kunci dengan kid baru, memublikasikan public key lama dan baru, dan memperbarui ETag. Kemudian saya menunggu jendela cache maksimum skenario selama 10 menit atau secara proaktif menyegarkan seluruh 200 verifier dan mengumpulkan kesiapan. Token canary membuktikan bahwa kunci baru berfungsi sebelum signer dialihkan.

Saya mencatat waktu penerbitan token lama terakhir. Public key lama dipertahankan setidaknya selama masa berlaku penerimaan 15 menit ditambah 1 menit clock skew, dan saya menghapusnya hanya setelah lalu lintas kid lama habis. Kedua gerbang transisi bersifat eksplisit: jangan menandatangani token baru sampai public key baru terpropagasi, dan jangan menghapus public key lama sampai token lama tidak valid.

Saat terjadi cache miss, setiap issuer mendapatkan satu penyegaran single-flight dengan timeout, cooldown, dan ETag. Jika kunci tetap tidak ada, tolak dan simpan dalam negative cache secara singkat. Nilai kid acak tidak dapat membesar menjadi banjir ke upstream. Selama kegagalan JWKS sementara, kunci yang dikenal dapat berlanjut hanya di dalam batas jendela basi yang dinyatakan, sementara kunci yang tidak dikenal selalu fail-closed.

Jika private key lama terkompromi, saya menghentikan penandatanganan lama, memublikasikan dan beralih ke kunci baru, menyiarkan pembatalan cache, dan mencabut token dalam rentang kid lama atau iat lama. Saya tidak mempertahankan tumpang tindih normal karena penyerang mungkin sedang menandatangani token. Terakhir, saya membuktikan penyelesaian dengan versi JWKS, usia cache, error verifikasi berdasarkan kid, canary kunci baru, dan pengamatan kid lama terakhir, serta saya rutin melatih transisi dan kegagalan issuer."

Kesalahan Umum

• Mengalihkan signer sebelum memublikasikan public key → layanan dengan JWKS basi menolak token baru → publikasikan, buktikan propagasi, baru mulai penandatanganan baru.
• Hanya memublikasikan kunci baru → token lama yang valid langsung gagal → publikasikan kedua generasi selama jendela penerimaan.
• Menunggu durasi arbitrer → durasi tersebut mungkin lebih pendek dari cache nyata atau masa berlaku token → turunkan gerbang dari keusangan maksimum, penerbitan lama terakhir, masa berlaku token, dan clock skew.
• Mengunduh JWKS untuk setiap permintaan → kegagalan issuer merusak semua autentikasi dan memperbesar beban → gunakan caching lokal, penyegaran kondisional, dan kebijakan basi terbatas.
• Menyegarkan untuk setiap kid yang tidak dikenal → pengidentifikasi acak menciptakan badai penyegaran → gunakan single-flight, rate limit, negative caching, dan batasan input.
• Mencoba setiap kunci untuk kid yang tidak dikenal → pemilihan kunci menjadi ambigu dan memperluas attack surface → segarkan sekali, lalu tolak tanpa kecocokan yang tepat.
• Memercayai alg atau jku dari token → kebingungan algoritma atau SSRF dapat terjadi → pin algoritma dan lokasi JWKS dalam konfigurasi verifier.
• Hanya memeriksa tanda tangan → token untuk issuer, audience, atau waktu lain dapat diterima → validasi juga iss, aud, exp, dan nbf.
• Menggunakan kembali kid dengan materi kunci baru → cache tidak dapat mengetahui bahwa satu pengidentifikasi telah berubah → tetapkan pengidentifikasi baru untuk setiap generasi kunci.
• Menganggap penghapusan JWKS pusat sebagai pencabutan langsung → verifier mungkin masih menyimpan cache lama → sediakan pembatalan cache dan pencabutan token eksplisit.
• Mempertahankan tumpang tindih normal setelah kompromi → penyerang dapat mencetak token di sepanjang jendela tersebut → gunakan jalur darurat dan terima reautentikasi yang diperlukan.

Pertanyaan Lanjutan dan Tanggapan

Pertanyaan Lanjutan 1: Berapa lama tepatnya public key lama harus dipertahankan?

Mulai dari waktu penerbitan token kunci lama terakhir, pertahankan setidaknya selama "masa berlaku penerimaan maksimum + clock skew." Dalam skenario ini, durasinya adalah 15 + 1 = 16 menit. Tambahkan penundaan antrean, penerbitan offline, atau jendela penerimaan implisit yang lebih lama jika ada. Amati lalu lintas kid lama sebelum penghapusan agar konfigurasi dan realitas runtime selaras.

Pertanyaan Lanjutan 2: Mengapa tidak langsung mengembalikan 401 untuk kid yang tidak dikenal?

Setelah rotasi yang sah, token baru dapat tiba sebelum penyegaran cache alami pada proses ini terjadi. Satu penyegaran terkontrol menutup celah tersebut. Penyegaran ini harus digabungkan, dibatasi kecepatannya, dan dibatasi hanya pada URL tepercaya; tolak hanya jika set terbaru masih belum memiliki kid, menyeimbangkan kompatibilitas dengan resistansi amplifikasi.

Pertanyaan Lanjutan 3: Haruskah verifikasi bersifat fail-open saat JWKS down?

Jangan pernah melewati verifikasi tanda tangan. Kunci cocok yang sudah dipercaya di cache dapat menyelesaikan validasi penuh dalam batas jendela basi yang eksplisit. Tolak kunci yang tidak dikenal atau permintaan setelah jendela tersebut. Ini mencegah pemadaman control-plane singkat memengaruhi setiap permintaan data-plane sambil tetap menjaga batas kepercayaan yang terukur.

Pertanyaan Lanjutan 4: Mengapa token lama masih bisa berfungsi setelah menghapus kunci yang terkompromi?

Verifier mungkin masih memiliki cache lama 10 menit, dan JWT mandiri tidak berkonsultasi dengan otoritas pusat. Jalur darurat harus membatalkan cache secara proaktif dan menerapkan aturan penolakan sementara berdasarkan kid lama, waktu penerbitan, atau versi token. Sistem berisiko tinggi dapat menggunakan introspeksi atau sesi sisi server untuk pencabutan yang lebih cepat.

Pertanyaan Lanjutan 5: Bagaimana Anda menghindari badai penyegaran (refresh storm) selama rotasi?

Prapublikasi memungkinkan sebagian besar proses memperoleh kunci selama penyegaran alami, dan penyegaran proaktif dapat diatur secara bertahap dengan jitter. Untuk miss nyata, gunakan satu single-flight per issuer, ditambah cooldown, ETag, timeout, dan negative caching singkat. Pantau volume permintaan JWKS dan kardinalitas kid yang tidak dikenal; batasi laju (rate-limit) anomali daripada mencoba ulang lebih keras.

Pertanyaan Lanjutan 6: Bagaimana gerbang penandatanganan dapat diotomatiskan?

Tetapkan versi untuk setiap JWKS. Verifier secara berkala melaporkan versi yang dimuat dan kid yang dikenali. Pengontrol rilis memerlukan tingkat kesiapan target dan keberhasilan token canary pada jalur kritis sebelum mengaktifkan private key. Setiap peningkatan kegagalan verifikasi kid baru akan menjeda atau me-rollback penandatanganan; membiarkan public key baru dipublikasikan tidak membahayakan token lama.

Pertanyaan Lanjutan 7: Bagaimana jika verifier pihak ketiga tidak dapat mengakui kesiapan?

Publikasikan kontrak tumpang tindih yang stabil: ekspos public key baru setidaknya satu periode cache maksimum lebih awal, pertahankan kunci lama sampai semua token lama kedaluwarsa, dan kirim header caching yang sesuai. Issuer tidak dapat memaksa pihak ketiga untuk menyegarkan cache, sehingga jendela kompatibilitas, pemberitahuan perubahan, dan pemeriksaan canary menggantikan pengakuan internal. Kompromi darurat masih dapat menyisakan jendela paparan yang tidak dapat dihindari.