Mengapa JWT Anda segera kedaluwarsa: exp dalam hitungan detik, bukan milidetik

Diterbitkan pada 10:00, kedaluwarsa pada 10:00 — token ditolak pada penggunaan pertama dan jam server bukan itu masalahnya

Token yang ditolak pada permintaan pertamanya menimbulkan kecurigaan adanya server yang miring, tetapi periksa klaim mentahnya sebelum mengubah jam. Jika satu komponen menghasilkan `exp` dari jam milidetik sementara komponen lainnya membandingkan detik NumericDate, nilainya berbeda tiga kali lipat. Tidak ada penyesuaian sinkronisasi biasa yang dapat menjelaskan kesenjangan tersebut.

Gunakan token yang dibuang atau disunting karena token pembawa adalah kredensial. Dekoder ToolAcre JWT membaca data muatan tetapi sengaja tidak memverifikasi tanda tangan. Salin klaim waktu numerik ke konverter stempel waktu hanya setelah mempertahankan perlengkapan pengujian asli dan masa pakai yang diharapkan.

Apa yang dikatakan RFC 7519 — Tanggal Numerik sebagai detik sejak 1970-01-01T00:00:00Z, dan mengapa berupa angka, bukan string

Artikel JWT yang diterbitkan di sebelahnya sudah menyatakan kontrak penting: `exp` NumericDate menghitung detik dari zaman Unix. Mengulangi penjelasan standarnya tidak akan menambah nilai apa pun di sini. Pertanyaan praktisnya adalah apakah setiap produser, serializer, verifikator, dan perlengkapan pengujian memenuhi skala yang sama.

Carilah kode batas yang eksplisit: jam milidetik dibagi menjadi beberapa detik saat dikeluarkan, dan perbandingan detik saat memvalidasi. Klaim tersebut harus tetap berupa angka, bukan format tanggal yang digunakan untuk aritmatika. UTC yang dapat dibaca manusia adalah proyeksi diagnostik, bukan representasi otoritatif token.

Sematkan kontrak ini dalam pengujian penerbit dan verifikator dengan nilai bukan nol. Pengujian menggunakan epoch zero tidak dapat mengungkapkan apakah salah satu sisinya dibagi atau dikalikan dengan seribu.

Artikel JWT yang ada menetapkan NumericDate detik; artikel ini menerapkan fakta itu pada proses debug yang kadaluwarsa

Jika pemverifikasi menafsirkan klaim detik yang valid sebagai milidetik, tanggalnya mendekati 1970 dan tampak kedaluwarsa. Jika penerbit menulis nilai milidetik saat ini ke dalam bidang yang kemudian ditafsirkan sebagai detik, masa berlakunya akan jauh melampaui masa pakai yang diharapkan atau melampaui rentang yang didukung perpustakaan. Gejala mana yang muncul mengidentifikasi pihak mana yang memiliki kesalahan skala.

Hindari “perbaikan” yang menerima kedua bentuk berdasarkan jumlah digit. Hal ini mengubah format token yang salah menjadi protokol alternatif permanen dan dapat menyembunyikan regresi penerbit. Tolak nilai yang melanggar kontrak NumericDate aplikasi, perbaiki pembuatannya, dan tambahkan perlengkapan yang membedakan detik dari milidetik.

Kesalahan milidetik dapat menyebabkan penolakan langsung atau kadaluwarsa yang sangat jauh, tergantung pihak mana yang salah

Dekode muatan untuk mengekspos `exp`, `iat` dan `nbf` sebagai nilai mentah sebelum kerangka kerja mengonversinya. Bandingkan `exp − iat` dengan masa pakai token yang diinginkan dalam hitungan detik. Periksa `nbf` secara terpisah; token mungkin belum kedaluwarsa namun tidak dapat digunakan. Jangan menyimpulkan keaslian dari waktu yang terlihat masuk akal.

Dekoder ToolAcre melaporkan bahwa verifikasi tanda tangan salah, sehingga keluarannya termasuk dalam proses debug, bukan otorisasi. Payload yang dimodifikasi dapat berisi masa berlaku apa pun yang dipilih penyerang. Pemverifikasi aplikasi tepercaya masih harus menerapkan kebijakan algoritma, kunci, penerbit, audiens, dan waktu pada token kompak asli.

Contoh praktis: exp 1700003600 — mengonversinya menjadi UTC dan waktu setempat, memeriksanya terhadap iat, dan memastikan masa pakainya sesuai dengan yang Anda inginkan

Untuk `iat = 1,700,000,000` dan `exp = 1,700,003,600`, pengurangan menghasilkan 3,600 detik, atau satu jam. Konverter membaca kedaluwarsa secara eksplisit dalam hitungan detik dan mengembalikan `2023-11-14T23:13:20.000Z`; waktu terbitnya adalah `2023-11-14T22:13:20.000Z`.

Angka-angka tersebut unik untuk contoh diagnostik artikel ini. Jika pemilihan milidetik menghasilkan pembacaan 1970 bulan Januari, hal tersebut diperkirakan merupakan bukti adanya skala yang salah. Konfirmasikan bahwa waktu verifikator saat ini juga dinyatakan dalam hitungan detik sebelum menyimpulkan kebijakan satu jam diterapkan dengan benar.

Perbedaan satu jam dihitung sebelum pemformatan, sehingga tetap satu jam di setiap zona. Tampilan lokal mungkin berbeda, namun `exp − iat` tidak.

Contoh praktis: bandingkan exp 1,700,003,600 dengan iat terdekat menggunakan detik eksplisit

Pemverifikasi mungkin mengizinkan toleransi kecil yang ditentukan aplikasi seputar klaim waktu untuk mengakomodasi perbedaan jam yang kecil. Repositori ini tidak menentukan jumlah detik yang disarankan, jadi tidak ada kelonggaran universal yang ditentukan di sini. Kebijakan keamanan dan konfigurasi perpustakaan adalah otoritasnya.

Toleransi harus tetap kecil dibandingkan dengan faktor seribu. Memperluasnya hingga klaim yang salah formatnya lolos akan melemahkan penegakan masa berlaku habis dan membiarkan bug penerbit tetap hidup. Pertama normalkan unit jam dan sinkronisasi; lalu putuskan apakah tunjangan terbatas sesuai dengan model ancaman aplikasi.

Jika toleransi dikonfigurasi, uji nilai di dalam dan di luar batas tersebut dalam hitungan detik. Hal ini membuktikan kebijakan secara independen dari tanggal atau rendering lokal mana pun.

Toleransi tidak dapat memperbaiki ketidakcocokan faktor-1,000

Konversi stempel waktu tidak dapat memverifikasi tanda tangan token, algoritme yang diizinkan, kunci, penerbit, atau audiens. Bahkan klaim `exp` di masa depan yang diformat dengan sempurna mungkin ada di dalam token palsu. Dekoder JWT sengaja dibuat transparan tentang batas ini dan harus dipasangkan dengan pemverifikasi tepercaya.

Hal ini juga tidak dapat menentukan apakah token produksi yang diambil telah dicabut atau apakah kebijakan sesi mengesampingkan masa berlaku nominalnya. Nilai debug dengan perlengkapan yang tidak sensitif. Jika insiden nyata memerlukan pemeriksaan kredensial, gunakan lingkungan resmi dan prosedur penanganan daripada alur kerja clipboard umum.

Penguraian kode harus dilakukan hanya dengan perlengkapan sintetis atau yang disunting dengan aman selama proses debug rutin. Menyalin kredensial pembawa langsung menimbulkan masalah keamanan yang tidak terkait dengan aritmatika stempel waktu.

Kesimpulan: exp adalah sepuluh digit, bukan tiga belas — dan bagaimana dekoder JWT dan konverter stempel waktu Unix berada di tab yang sama sehingga Anda dapat memeriksa klaim dalam hitungan detik

Perlakukan klaim waktu JWT sebagai detik pada setiap batas dan uji perbedaannya sebagai durasi. Konverter stempel waktu mengubah klaim individual menjadi UTC dan konteks lokal; dekoder JWT menampilkan angka mentah. Bersama-sama mereka menjelaskan waktu tanpa menuntut kepercayaan.

Koreksi yang tahan lama terjadi pada penerbitan dan kode verifikasi, bukan pada runbook dukungan yang mengubah unit hingga token berfungsi. Pertahankan detik eksplisit, tolak skala yang salah format, dan pertahankan verifikasi tanda tangan sebagai keputusan wajib terpisah.

Pemisahan tersebut juga meningkatkan kemampuan observasi: log pembuatan dapat melaporkan kebijakan durasi tanpa mengekspos token, sementara metrik verifikasi dapat membedakan hasil tanda tangan yang kedaluwarsa, prematur, dan tidak valid.