Penyahkod JWT

Tampal sebarang token JWT dan serta-merta lihat pengepala dan muatan yang dinyahkod sebagai JSON berformat.

Penyahkod kami:

• mengenal pasti algoritma tandatangan
• memaparkan semua tuntutan piawai dan tersuai
• menukar cap masa Unix kepada tarikh yang boleh dibaca manusia

Paparan berkod warna memudahkan anda membezakan tiga bahagian JWT.

Nyahpepijat isu JWT dengan menyemak masa tamat tempoh, cap masa dikeluarkan, dan nilai tuntutan.

Alat kami menunjukkan sama ada token telah tamat tempoh, berapa lama lagi sebelum tamat tempoh, dan mengetengahkan potensi isu.

Penting untuk:

• pembangunan API
• penyahpepijatan pengesahan
• audit keselamatan

Sebuah Token Web JSON (JWT) ialah cara yang padat dan selamat untuk URL bagi mewakili tuntutan yang dipindahkan antara dua pihak, seperti yang ditentukan oleh RFC 7519 daripada IETF.

JWT mempunyai tiga bahagian yang diasingkan oleh titik, setiap satunya dikodkan dengan Base64URL mengikut RFC 4648:

• pengepala yang mengisytiharkan algoritma tandatangan dan jenis token menggunakan JSON (RFC 8259)
• muatan yang membawa tuntutan — kenyataan tentang entiti seperti pengguna, berserta metadata seperti tarikh luput
• tandatangan yang mengikat pengepala dan muatan bersama-sama supaya sebarang usikan boleh dikesan

Struktur ini membolehkan perkhidmatan mengesahkan identiti tanpa carian pangkalan data, sebab itulah JWT lazim digunakan dalam pengesahan tanpa keadaan dan aliran OpenID Connect.

Untuk menyahkod JWT, pecahkan token pada dua tanda titik kepada tiga segmen, kemudian nyahkod Base64URL untuk dua yang pertama.

Segmen pertama menghasilkan JSON pengepala, dan yang kedua menghasilkan JSON muatan, kedua-duanya boleh dibaca sebagai teks biasa mengikut RFC 8259.

Base64URL (RFC 4648, seksyen 5) menggantikan '+' dengan '-' dan '/' dengan '_' serta melangkau padding, jadi penyahkod Base64 standard mungkin gagal tanpa pelarasan. Alat kami mengendalikan perkara ini secara automatik dan mencetak keputusan dengan kemas.

Segmen ketiga, iaitu tandatangan, tidak dinyahkod kepada teks kerana ia adalah nilai kriptografi mentah.

Seperti yang dinyatakan oleh Dokumen Web MDN, menyahkod bukanlah pengesahan — membaca muatan tidak pernah mengesahkan bahawa token itu tulen.

Tidak — JWT yang ditandatangani standard (JWS) adalah dikodkan, bukan disulitkan, jadi sesiapa sahaja yang memegang token boleh membaca muatannya.

Pengekodan Base64URL (RFC 4648) boleh diterbalikkan dan memberikan kerahsiaan sifar; ia hanya membolehkan pengangkutan selamat perduaan. Tandatangan yang diterangkan dalam RFC 7515 (Tandatangan Web JSON) melindungi integriti dan keaslian, bukan kerahsiaan.

Jika anda perlukan kandungan disembunyikan, gunakan JWE (Penyulitan Web JSON, RFC 7516) sebagai gantinya.

OWASP dan IETF kedua-duanya menekankan perbezaan ini: jangan sekali-kali meletakkan kata laluan, rahsia API, atau data peribadi yang boleh dikenal pasti dalam muatan JWT yang ditandatangani, kerana penyahkod seperti ini mendedahkan setiap tuntutan dalam teks biasa tanpa sebarang kunci.

Tuntutan JWT berdaftar diselaraskan oleh RFC 7519 supaya sistem yang berbeza mentafsirkannya secara konsisten.

Set teras merangkumi:

• 'iss' (pengeluar)
• 'sub' (subjek, prinsipal token)
• 'aud' (khalayak, penerima yang diniatkan)
• 'exp' (masa tamat tempoh)
• 'nbf' (bukan sebelum)
• 'iat' (dikeluarkan pada)
• 'jti' (ID token unik)

Nilai exp, nbf, dan iat adalah nilai NumericDate — saat sejak epoch Unix — yang ditukar oleh penyahkod kami kepada tarikh yang boleh dibaca manusia. Aplikasi menambah tuntutan tersuai (peribadi) untuk peranan, skop, atau ID penyewa.

Mengikut spesifikasi, pengesah mesti menolak token yang 'exp'-nya telah berlalu atau 'aud'-nya tidak sepadan dengan khalayak yang dijangkakan, bagi mencegah penyalahgunaan merentas perkhidmatan.

Algoritma tandatangan JWT ditentukan dalam RFC 7518 (Algoritma Web JSON) dan dikenal pasti melalui nilai 'alg' pengepala.

• Algoritma HMAC (HS256, HS384, HS512) menggunakan satu rahsia berkongsi tunggal untuk kedua-dua penandatanganan dan pengesahan, yang ringkas tetapi memerlukan setiap pengesah memegang rahsia itu.
• Algoritma RSA (RS256, RS384, RS512) dan RSASSA-PSS (PS256) menggunakan kunci peribadi untuk menandatangani dan kunci awam untuk mengesahkan, sesuai untuk sistem teragih dan OpenID Connect.
• Algoritma ECDSA (ES256, ES384, ES512) menawarkan keselamatan setara dengan kunci dan tandatangan yang lebih kecil.

NIST menerbitkan standard asas SHA-2 dan ECDSA. Penyahkod kami membaca medan 'alg' supaya anda boleh mengesahkan skema yang digunakan oleh sesuatu token.

JWT digunakan secara meluas untuk pengesahan tanpa keadaan, kebenaran, dan pertukaran maklumat selamat dalam API moden.

Selepas pengguna log masuk, pelayan mengeluarkan JWT yang ditandatangani yang dikembalikan oleh pelanggan dalam pengepala HTTP Authorization sebagai token Bearer, mengikut RFC 6750. Kerana tandatangan itu terkandung sendiri, perkhidmatan bahagian belakang boleh mengesahkan token tanpa menyoal simpanan sesi, meningkatkan skalabiliti.

JWT juga menguasakan token ID OpenID Connect dan corak token akses OAuth 2.0.

Pembangun menggunakan penyahkod semasa penyahpepijatan untuk memeriksa tuntutan, mengesahkan nilai audien dan pengeluar, dan menyemak tarikh luput apabila API mengembalikan ralat 401. Seperti yang diterangkan oleh MDN Web Docs, aliran berasaskan token ini menyokong banyak seni bina log masuk tunggal dan perkhidmatan mikro.

Penggunaan JWT yang selamat tertumpu pada pengesahan algoritma, pengesahan tandatangan, dan penguatkuasaan tarikh luput.

OWASP memberi amaran terhadap serangan 'alg: none' klasik dan serangan kekeliruan algoritma, di mana pelayan yang tertipu untuk melayan kunci awam RS256 sebagai rahsia HMAC boleh dipalsukan; sentiasa tetapkan algoritma yang dijangka daripada mempercayai pengepala.

Amalan utama:

• Gunakan jangka hayat 'exp' yang singkat dengan token muat semula, dan sahkan 'iss' dan 'aud' pada setiap permintaan.
• Jangan sekali-kali simpan rahsia dalam muatan, kerana ia hanya dikodkan Base64.
• Hantar token secara eksklusif melalui HTTPS, dan pertimbangkan strategi pembatalan kerana JWT standard tidak boleh dibatalkan secara individu sebelum tamat tempoh.

Mengikuti cadangan IETF dan OWASP ini menutup kerentanan JWT yang paling banyak dieksploitasi.

Kesilapan paling lazim semasa bekerja dengan JWT termasuk:

• Mengelirukan penyahkodan dengan pengesahan: membaca muatan dengan penyahkod tidak membuktikan apa-apa tentang keaslian, kerana sesiapa sahaja boleh membuat token yang tidak ditandatangani atau dipalsukan.
• Mempercayai nilai 'alg' pengepala secara membabi buta, yang membolehkan serangan kekeliruan algoritma yang ditandakan oleh OWASP.
• Salah membaca tarikh luput dengan membandingkan saat epoch 'exp' dengan milisaat, menyebabkan token yang sah kelihatan telah tamat tempoh.
• Menggunakan penyahkod Base64 standard dan bukannya Base64URL (RFC 4648), yang boleh merosakkan output kerana abjad yang berbeza dan padding yang hilang.
• Menempatkan data sensitif dalam muatan, yang menyebabkannya bocor, kerana token tersebut dikodkan, bukan disulitkan.

Mengesahkan tandatangan di sebelah pelayan dengan kunci dan algoritma yang dijangka mengelakkan perangkap ini.

Penyahkod JWT ini memproses token sepenuhnya pada sisi pelanggan, jadi token anda tidak pernah meninggalkan peranti anda atau sampai ke mana-mana pelayan.

Kerana JWT yang ditandatangani hanya dikodkan Base64URL (RFC 4648), penyahkodan tidak memerlukan panggilan rangkaian — pengepala dan muatan hanya diterbalikkan daripada bentuk terkodnya menggunakan JavaScript dalam pelayar anda.

Menjaga operasi ini tetap tempatan penting untuk keselamatan: token selalunya mengandungi kelayakan sesi langsung, dan menampalnya ke dalam alat sebelah pelayan boleh mendedahkannya dalam log atau transit. OWASP mengesyorkan meminimumkan tempat kelayakan sensitif bergerak.

Penyahkod khusus pelayar membolehkan pembangun memeriksa token pengeluaran dengan selamat semasa penyahpepijatan sambil menghormati prinsip pendedahan minimum, tanpa menghantar data kebenaran kepada pihak ketiga.