Generator JWT
Rahasia Anda hanya dipakai di halaman ini dan tidak pernah dikirim, disimpan, atau dimasukkan ke URL — jadi tautan yang dibagikan tidak bisa membocorkannya. Jangan pernah menempelkan rahasia penandatanganan produksi ke situs mana pun, termasuk situs ini; pakai rahasia sekali pakai untuk pengujian.
Hanya HS256, HS384, dan HS512 yang didukung. Penandatanganan RS, ES, dan PS memerlukan kunci privat, dan alat ini sengaja tidak memintanya.
Apa pun yang Anda masukkan di sini tidak disimpan, dicatat, atau dibagikan.
Susun payload JWT, pilih algoritmenya, lalu tandatangani dengan rahasia Anda. Penandatanganan berjalan sepenuhnya di peramban Anda, jadi rahasia itu tidak pernah keluar dari perangkat.
Cara memakai
- Sunting payload sebagai JSON.
- Bila perlu pilih masa berlaku, yang otomatis menambahkan iat dan exp.
- Masukkan rahasia Anda; token yang sudah ditandatangani muncul di bawah.
Apa yang dihasilkan penandatanganan
JWT adalah tiga segmen base64url yang digabung dengan titik. Yang pertama adalah header, yang menyebut algoritma yang dipakai. Yang kedua adalah payload, berisi claim Anda. Yang ketiga adalah tanda tangan, dihitung dari dua segmen pertama yang digabung dengan titik - yang ditandatangani adalah byte persis dari segmen-segmen itu, bukan JSON hasil decode-nya, itulah sebabnya menserialisasi ulang token membuatnya tidak valid.
Dengan HS256, tanda tangannya adalah HMAC dari input tersebut memakai secret Anda. Siapa pun yang memegang secret yang sama bisa menghitung ulang dan melihat apakah hasilnya cocok, yang membuktikan dua hal: token diterbitkan oleh pihak yang mengetahui secret, dan tidak ada isinya yang diubah sejak itu. Ubah satu karakter saja di payload dan tanda tangan yang dihitung ulang tidak akan cocok lagi.
Yang tidak dilakukannya adalah menyembunyikan apa pun. Payload hanya dikodekan, bukan dienkripsi, dan siapa pun yang memegang token bisa membaca semua claim tanpa secret. Jangan pernah memasukkan kata sandi, nomor kartu, atau apa pun yang tidak ingin Anda cetak di log ke payload JWT.
Memilih secret
RFC 7518 mewajibkan kunci HMAC setidaknya sebesar output hash-nya: 256 bit untuk HS256, 384 untuk HS384, 512 untuk HS512. Artinya minimal 32 byte acak, bukan frasa yang mudah diingat.
Alasannya, JWT adalah bahan serangan offline yang sudah lengkap. Token berisi input yang ditandatangani sekaligus tanda tangannya, jadi siapa pun yang mendapatkan satu token bisa mencoba kandidat secret secepat perangkat kerasnya mampu, tanpa bolak-balik jaringan dan tanpa pembatasan laju. Ada alat yang dipublikasikan untuk melakukan persis hal itu, dan kata dari kamus atau string pendek jebol dalam hitungan detik. Token bocor dengan secret yang lemah berarti penyerang bisa menerbitkan tokennya sendiri dengan claim apa pun.
Gunakan nilai acak dari pengelola kata sandi atau generator kunci, pakai secret terpisah untuk setiap lingkungan agar token dari staging tidak bisa dipakai ulang di produksi, dan rotasi secara berkala seperti kredensial lainnya.
Claim yang layak diisi
Selain apa pun yang dibutuhkan aplikasi Anda, RFC 7519 mendaftarkan sekumpulan kecil claim standar. iss menyebut penerbit, sub mengidentifikasi subjek, aud menyebut audiens yang dituju, dan jti memberi token id unik sehingga bisa dicabut satu per satu atau diperiksa dari pemakaian ulang. Tiga claim waktu - exp untuk kedaluwarsa, nbf untuk saat paling awal token berlaku, iat untuk waktu penerbitan - adalah nilai NumericDate, yaitu detik sejak epoch Unix.
Detik, bukan milidetik. Memasukkan timestamp JavaScript secara langsung adalah satu-satunya alasan paling umum token buatan tangan ditolak: exp sepanjang tiga belas digit diurai sebagai tanggal jauh di masa depan, yang langsung ditolak oleh sebagian pustaka dan diterima oleh pustaka lain sebagai token yang tidak pernah kedaluwarsa.
Mengisi exp saja tidak membuat token kedaluwarsa. Token kedaluwarsa karena verifier memeriksa claim tersebut, dan verifier yang hanya memeriksa tanda tangan akan dengan senang hati menerima token dari tahun lalu. Kebanyakan pustaka juga memberi toleransi selisih jam yang kecil, biasanya satu atau dua menit, karena jam mesin penerbit dan verifier jarang benar-benar sama.
Mengapa hanya algoritma HS, dan jebakan alg
Keluarga HS bersifat simetris: satu secret bersama dipakai untuk menandatangani sekaligus memverifikasi, sehingga penandatanganan bisa dilakukan di sini hanya dengan apa yang Anda ketik. RS, ES, dan PS bersifat asimetris dan mengharuskan menempelkan kunci privat ke halaman web, sesuatu yang tidak mau diminta alat ini.
Field header yang menyebut algoritma juga menjadi tempat dua serangan terkenal. Yang pertama adalah alg: none, yang menyatakan token tidak ditandatangani; pustaka yang menurutinya bisa menerima token palsu dengan tanda tangan kosong. Yang kedua adalah penggantian algoritma: ambil token yang ditandatangani dengan RS256, ubah header-nya menjadi HS256, lalu tandatangani dengan kunci publik penerbit sebagai secret HMAC. Verifier yang membaca algoritma dari token, alih-alih menentukannya di awal, akan meloloskannya, karena kunci publik bukan rahasia.
Pertahanan untuk keduanya sama dan harus ada di verifier, bukan di penerbit: kunci algoritma yang diharapkan di pemanggilan verifikasi dan tolak token apa pun yang header-nya tidak sesuai.
Merancang masa hidup sebuah token
Keputusan paling berdampak dalam sistem token adalah berapa lama sebuah token hidup, karena JWT tidak bisa ditarik kembali sebelum kedaluwarsa. Masa hidup pendek - lima sampai lima belas menit untuk access token - menjaga jendela risiko token yang bocor tetap sempit dan merupakan jawaban standarnya, dipasangkan dengan refresh token berumur lebih panjang yang bisa dicabut karena server menyimpannya.
Rotasi refresh token membuat pasangan itu jauh lebih aman: setiap kali di-refresh, refresh token baru diterbitkan dan yang lama dibatalkan, sehingga token yang dicuri hanya bisa dipakai sekali. Kalau yang lama diajukan lagi, server jadi tahu bahwa dua pihak memegangnya dan bisa mencabut seluruh rangkaiannya.
Ketika yang dibutuhkan benar-benar kredensial berumur panjang, misalnya integrasi antarmesin atau sebuah CLI, JWT biasanya bukan bentuk yang tepat. API key yang dicocokkan ke basis data bisa dicabut seketika, dibatasi cakupannya dengan presisi, dan ditampilkan di antarmuka tempat pemiliknya melihat kapan terakhir kali dipakai.
Kunci, rotasi, dan header kid
Kunci penandatangan harus bisa dirotasi tanpa membuat layanan mati, dan mekanismenya adalah header kid: penerbit menyebutkan kunci mana yang menandatangani token, dan pemverifikasi mencari kunci itu alih-alih menebak. Dengan HS256 itu berarti sebuah peta kecil dari pengenal kunci ke secret; dengan RS256 atau ES256 itu berarti dokumen JWKS yang diambil dan disimpan di cache oleh pemverifikasi.
Rotasi kemudian punya tiga tahap. Publikasikan kunci baru supaya para pemverifikasi mengenalnya, alihkan penandatanganan ke kunci baru sambil tetap menerima yang lama, lalu pensiunkan kunci lama setelah semua token yang ditandatangani dengannya kedaluwarsa. Melewatkan masa tumpang tindih inilah yang mengubah rotasi rutin menjadi insiden.
Algoritma asimetris sepadan dengan persiapan tambahannya begitu ada lebih dari satu layanan yang memverifikasi token Anda. Dengan HS256 setiap pemverifikasi memegang secret yang juga bisa dipakai menandatangani, jadi satu layanan yang jebol saja sudah cukup untuk mencetak token; dengan RS256 pemverifikasi hanya memegang kunci publik dan tidak bisa memalsukan apa pun.
Apa yang pantas ada di payload, dan apa yang tidak
Token adalah kredensial bearer yang ikut di header pada setiap permintaan, jadi ukurannya punya biaya nyata: proxy umumnya membatasi header di 8 KB, dan token yang gembung dibayar pada tiap panggilan. Isinya cukup identitas dan beberapa fakta yang dibutuhkan pemverifikasi: subject, issuer, audience, waktu kedaluwarsa, serta sekumpulan kecil scope atau peran.
Apa pun yang mudah berubah tidak cocok di sini. Izin yang ditanam di dalam token sudah basi sejak detik ia diterbitkan, sehingga peran yang dicabut pukul 10.00 masih tetap diklaim oleh token sampai token itu kedaluwarsa. Kalau hal itu penting, token sebaiknya hanya membawa identitas dan layanan yang mencari otorisasinya, atau masa hidupnya dibuat cukup pendek sehingga kebasian itu masih bisa diterima.
Hal rahasia sama sekali tidak punya tempat di sana. Payload itu di-encode, bukan dienkripsi, jadi siapa pun yang memegang token bisa membaca seluruh claim: jangan ada catatan internal, jangan ada data pribadi di luar yang memang diperlukan penerima, jangan ada kunci. Kalau sebuah payload benar-benar harus rahasia, itu ranah JWE, spesifikasi yang berbeda dengan perkakas yang berbeda pula.
Menguji token tanpa membocorkan apa pun
Generator paling berguna untuk membuat fixture: token yang sudah kedaluwarsa, token yang belum berlaku, token dengan audience yang salah, token yang ditandatangani dengan kunci yang salah. Rutinitas verifikasi sebaiknya diuji terhadap keempatnya, dan sebagian besar bug di area ini adalah kasus ketika salah satunya justru diterima.
Gunakan secret khusus pengujian, jangan pernah yang produksi. Alasannya sama seperti untuk kredensial apa pun, dan di sini lebih tajam karena token beserta tanda tangannya saja sudah cukup untuk menyerang secret itu secara offline. Memisahkan secret per lingkungan juga mencegah kegagalan yang lebih halus, yaitu token yang dicetak di staging ternyata diterima di produksi.
Semua yang ada di halaman ini berjalan di peramban, jadi apa pun yang Anda ketik di sini tidak dikirim atau disimpan. Itu layak diketahui mengingat apa yang biasa orang tempel ke perkakas token, dan itu pula sebabnya algoritma asimetris tidak tersedia: menandatangani dengan RS256 berarti menempelkan kunci privat ke sebuah halaman web, dan tidak ada perkakas yang pantas memintanya.
Alasan umum token buatan tangan ditolak
Claim waktu dalam milidetik adalah yang paling sering. NumericDate adalah jumlah detik sejak epoch, jadi exp dengan tiga belas digit dibaca sebagai tanggal puluhan ribu tahun ke depan - langsung ditolak oleh sebagian pustaka, diterima sebagai token abadi oleh sebagian lain, dan keduanya bukan yang Anda inginkan.
Berikutnya padding. Segmen JWT memakai base64url tanpa padding, jadi token yang segmennya berakhir dengan tanda sama dengan, atau yang mengandung karakter plus dan garis miring alih-alih minus dan garis bawah, di-encode dengan alfabet yang keliru dan akan gagal bahkan sebelum tanda tangannya diperiksa.
Sisanya biasanya ketidakcocokan. Audience yang diharapkan pemverifikasi berbeda hanya karena satu garis miring di akhir; issuer ditulis dengan http padahal pemverifikasi memakai https; jam di salah satu mesin meleset beberapa menit dan tidak ada toleransi selisih waktu yang dikonfigurasi. Ketika token bisa di-decode dengan benar tapi tetap ditolak, bandingkan claim-nya dengan konfigurasi pemverifikasi bidang demi bidang sebelum mencurigai tanda tangannya.
Pertanyaan umum
- Apakah aman memasukkan rahasia penandatanganan saya?
- Rahasia itu hanya dipakai oleh JavaScript di halaman ini. Ia tidak pernah dikirim, disimpan, atau ditulis ke URL, jadi berbagi tautan tidak bisa membocorkannya. Meski begitu, perlakukan rahasia produksi seperti kata sandi dan pakai nilai sekali pakai untuk pengujian.
- Kenapa hanya HS256, HS384, dan HS512 yang didukung?
- Ketiganya simetris, jadi satu rahasia bersama dipakai untuk menandatangani sekaligus memverifikasi. RS, ES, dan PS bersifat asimetris dan akan menuntut Anda menempelkan kunci privat ke formulir web, sesuatu yang sengaja tidak diminta alat ini.
- Apa yang harus diisi di iat dan exp?
- Keduanya bernilai NumericDate yang diukur dalam detik sejak epoch Unix, bukan milidetik. Memilih masa berlaku di sini menuliskan keduanya dengan benar; mengisinya dalam milidetik adalah cara paling umum sebuah token buatan tangan berakhir ditolak.
- Bisakah saya menambahkan kolom header sendiri?
- Header diisi dengan algoritme pilihan Anda ditambah typ JWT. Kolom tambahan seperti kid berkaitan dengan pengaturan manajemen kunci tertentu, jadi lebih baik ditambahkan oleh pustaka yang menerbitkan token asli Anda.
- Apakah token ini boleh dipakai di produksi?
- Tidak. Ini alat untuk pengujian dan penelusuran masalah. Token sungguhan harus diterbitkan oleh layanan autentikasi Anda, yang mengurus rotasi kunci, pencabutan, dan validasi klaim.
Terakhir diperbarui:
Sertakan langkah, hasil yang diharapkan, dan hasil sebenarnya. Hapus rahasia dan data pribadi.