Membaca JWT: klaim terlihat belum tentu terverifikasi
Saat mengembangkan integrasi, memeriksa kolom JWT membantu diagnosis. Membacanya tidak membuat isinya fakta terbukti atau memberi izin bertindak.
Apa yang bisa terlihat?
Bentuk ringkas 3 bagian dapat menampilkan header dan payload yang dapat didekode. Isinya bisa berupa nama algoritma, subjek, audiens tujuan, dan kedaluwarsa.
Alat menampilkan struktur ini secara lokal; tidak mendekripsi token JWE. Payload yang terbaca juga tidak menyembunyikan informasi dari siapa pun yang memegang token.
Referensi: RFC 7519 — JSON Web Token claims, NumericDate and trust decisions
Decoding tidak mengautentikasi penerbit
Keputusan percaya perlu verifikasi kriptografis dan konteks aplikasi yang benar. Nama algoritma atau izin dalam payload tidak membuktikan penerbit yang semestinya.
Di sini verified=false selalu: tanda tangan, identitas penerbit, kedaluwarsa, dan otorisasi tidak diperiksa. Tentukan akses dengan mekanisme verifikasi resmi aplikasi, bukan teks decoder.
Referensi: RFC 7519 — JSON Web Token claims, NumericDate and trust decisions
Baca waktu dengan tepat, tangani token dengan hati-hati
exp standar adalah detik sejak epoch Unix, bukan milidetik atau tanggal lokal. Membaca tanggal tidak berarti decoder membandingkannya dengan jam saat ini.
Jangan masukkan token nyata ke percakapan, dokumen dukungan, atau tangkapan layar publik. Belajar memakai data sintetis; bisa membaca token setelah diubah bukan bukti token akan diterima.
Referensi: RFC 7519 — JSON Web Token claims, NumericDate and trust decisions
Contoh diagnosis tanpa memberi izin
Payload sintetis {"sub":"example-reader","exp":1893456000} menunjukkan exp pada 2030-01-01T00:00:00Z. Itu penafsiran kolom, bukan bukti sistem tepercaya menerbitkannya.
Payload terbaca bisa didekode walau tanda tangannya tidak valid secara kriptografis; hasil tetap verified=false. Mengubah sub atau exp tidak mengizinkan token baru, dan tanda tangan panjang tidak bisa diverifikasi hanya dengan dilihat.