Why doesn't this tool verify the JWT signature?

Signature verification requires the signing secret or public key, which is kept private on your server. This tool decodes and displays the header and payload for inspection, but cryptographic verification must happen on your backend. Never trust an unsigned or unverified JWT in production.

What information can I see in a JWT payload?

The payload contains claims (data assertions) such as: exp (expiration time), iss (issuer), sub (subject/user), aud (audience), and custom claims. Always check the exp claim to ensure the token hasn't expired. Additional claims depend on how the token was issued.

Is this tool secure for sensitive data?

Yes, all processing runs entirely in your browser. No data is sent to any server, making it safe for sensitive information.

Dekoder JWT Gratis

Dekode dan inspeksi JSON Web Tokens · header, payload, klaim, dan kadaluarsa.

Tempel Token JWT

Header

Payload

Tanda Tangan

Tentang JWTs

JSON Web Tokens (JWTs) adalah cara ringkas untuk merepresentasikan klaim antara dua pihak. Mereka terdiri dari tiga bagian: header (algoritma dan tipe), payload (klaim seperti penerbit, kadaluarsa, subjek), dan tanda tangan. Alat ini mendekode header dan payload tetapi tidak memverifikasi tanda tangan · untuk itu, Anda memerlukan rahasia penandatanganan atau kunci publik. Semua pendekodean terjadi di browser Anda; token Anda tidak pernah dikirim ke mana pun.

Sejarah singkat JSON Web Token

JSON Web Token (JWT) distandardisasi sebagai RFC 7519 pada Mei 2015 oleh Michael B. Jones (Microsoft), John Bradley (Ping Identity), dan Nat Sakimura (NRI) di bawah Kelompok Kerja JOSE IETF. Itu adalah puncak dari setengah dekade pekerjaan: draf internet JWT pertama muncul pada Desember 2010, tumbuh dari format aserisi berbasis XML yang berat dari SAML 2.0 (2005) dan kebutuhan yang dirasakan akan sesuatu yang lebih ringan yang dapat dianalisis browser secara native. Terobosan adalah memilih JSON daripada XML dan base64url daripada PEM: JWT dapat masuk ke dalam string kueri URL atau header Authorization: Bearer. Seluruh keluarga JOSE dikirim sebagai set terkoordinasi: RFC 7515 (JWS) untuk penandatanganan, RFC 7516 (JWE) untuk enkripsi, RFC 7517 (JWK) untuk format kunci, RFC 7518 (JWA) untuk pengidentifikasi algoritma, dan RFC 7519 (JWT) untuk lapisan klaim, semuanya pada hari yang sama di Mei 2015. Adopsi instan. OAuth 2.0 (RFC 6749, 2012) telah menstandardisasi token akses tetapi membiarkan formatnya tidak transparan; industri memilih JWT. OpenID Connect (Desember 2014, OpenID Foundation) membuat JWT wajib untuk token ID. Pada 2017, setiap penyedia identitas besar (Auth0, Okta, Azure AD, AWS Cognito, Google Identity, Firebase Auth) mengeluarkan JWT sebagai format sesi native mereka. JWT.io, situs web dekoder yang diluncurkan Auth0 pada 2014, menjadi alat de facto debugging JWT dan membantu menyemen mindshare pengembang terhadap format. Dua insiden keamanan membentuk model ancaman modern: pengungkapan Tim McLean pada 2015 tentang bypass alg: none dan serangan kebingungan algoritma HS/RS, dan CVE-2022-21449 (April 2022), bug «Psychic Signatures» Neil Madden di verifier ECDSA Java 15-18. Keduanya menyebabkan pengerasan default pustaka: sebagian besar pustaka modern sekarang menolak alg: none langsung dan menyematkan algoritma yang diharapkan daripada membacanya dari header token.

Anatomi sebuah JWT

Tiga segmen yang dikodekan base64url. JWT adalah string header.payload.signature: tiga segmen yang dipisahkan oleh titik, masing-masing dikodekan base64url. RFC 7519 menyebutnya JWT Compact Serialization. Semuanya muat dalam URL atau header HTTP; kekompakan itu adalah tujuan desain yang membedakan JWT dari pendahulunya berbasis XML seperti SAML.
Header. Objek JSON kecil yang biasanya berisi dua bidang: alg (algoritma penandatanganan, mis. HS256, RS256, ES256) dan typ (hampir selalu «JWT»). Bidang opsional termasuk kid (pengidentifikasi kunci yang digunakan untuk rotasi kunci) dan cty (jenis konten untuk token bersarang). Header memberi tahu verifier bagaimana memvalidasi tanda tangan; jangan pernah mempercayainya sendirian, selalu sematkan algoritma yang diharapkan di sisi server.
Payload. Objek JSON dari klaim, aserisi kunci-nilai tentang subjek. RFC 7519 §4.1 mencadangkan tujuh klaim standar: iss (penerbit), sub (subjek), aud (audiens), exp (kedaluwarsa), nbf (tidak sebelum), iat (diterbitkan pada), dan jti (ID JWT unik). Penerbit menambahkan klaim kustom dengan bebas. Payload ditandatangani tetapi tidak dienkripsi: siapa pun yang memiliki token dapat membacanya.
Tanda tangan. Bukti kriptografis bahwa header dan payload tidak dirusak. Input penandatanganan adalah string harfiah base64url(header) + "." + base64url(payload); tanda tangan itu sendiri kemudian dikodekan base64url sebagai segmen ketiga. Verifikasi memerlukan rahasia simetris (HS*) atau kunci publik asimetris (RS*, ES*, PS*, EdDSA) dan harus selalu terjadi di server tepercaya.
base64url, bukan base64. Segmen JWT menggunakan varian base64 aman-URL yang didefinisikan dalam RFC 4648 §5: karakter 62 adalah - alih-alih +, karakter 63 adalah _ alih-alih /, dan padding = belakang dihilangkan. atob() bawaan JavaScript hanya menangani base64 standar, jadi dekoder JWT menerjemahkan alfabet dan mengisi ulang sebelum mendekode.
NumericDate: detik, bukan milidetik. RFC 7519 mendefinisikan exp, nbf, dan iat sebagai «jumlah detik dari 1970-01-01T00:00:00Z UTC». Date.now() JavaScript mengembalikan milidetik, jadi bug umum adalah exp tiga orde besarnya terlalu besar, menghasilkan token yang «kedaluwarsa» sekitar tahun 53.000. Selalu gunakan Math.floor(Date.now() / 1000) saat mencetak token.

Di mana JWT digunakan dalam praktik

Token akses OAuth 2.0. RFC 6749 membiarkan format token akses tidak transparan, tetapi dalam praktik industri menstandardisasi pada JWT. Auth0, Okta, Azure AD, AWS Cognito, dan Google Identity semua mengeluarkan token akses JWT secara default. Token Bearer di header Authorization Anda hampir selalu JWT.
Token ID OpenID Connect. OIDC (Desember 2014) mewajibkan JWT untuk id_token-nya. id_token membawa klaim identitas tentang pengguna yang diautentikasi (sub, email, name, picture) dan dikonsumsi oleh pihak yang mengandalkan daripada diteruskan. Ini adalah mekanisme utama di balik «Masuk dengan Google», «Masuk dengan Apple», dan alur yang setara.
Autentikasi API. API REST stateless mengadopsi JWT karena menghilangkan kebutuhan untuk penyimpanan sesi sisi server: API mempercayai apa yang diverifikasi tanda tangan. Kunci API gaya Stripe tetap umum untuk lalu lintas server-ke-server, tetapi untuk API berskop pengguna, pola Authorization: Bearer <jwt> sekarang adalah default.
Autentikasi microservice-ke-microservice. JWT berskop pengguna yang dicetak di tepi API diteruskan melalui panggilan layanan-ke-layanan internal, memungkinkan setiap layanan mempercayai autentikasi asli tanpa autentikasi ulang. Pola ini kadang-kadang disebut «terjemahan token»: gateway tepi menukar sesi tidak transparan dengan JWT berdurasi singkat yang berskop ke panggilan downstream.
Sesi aplikasi halaman tunggal. SPA (React, Vue, Angular) secara historis menyimpan token akses di localStorage untuk kemudahan. Panduan modern (OWASP, Auth0) adalah menyimpan token akses di memori dan token penyegaran di cookie HttpOnly + Secure + SameSite=Strict, karena localStorage dapat dibaca oleh XSS apa pun yang mendarat di halaman.
Sesi aplikasi seluler. Aplikasi iOS dan Android menyimpan token akses di Keychain atau Keystore platform. Token dikirim sebagai Authorization: Bearer pada setiap panggilan backend. Token penyegaran dirotasi pada setiap penggunaan, dan exp pendek token akses (biasanya 5-15 menit) adalah pertahanan utama terhadap pemutaran ulang perangkat yang dicuri.

Standar dan tonggak sejarah keamanan

RFC 7519 (JWT, Mei 2015). Spesifikasi dasar. Mendefinisikan JWT Compact Serialization, tujuh klaim standar terdaftar (iss, sub, aud, exp, nbf, iat, jti), dan format NumericDate. Penulis: Michael B. Jones, John Bradley, Nat Sakimura.
RFC 7515 (JWS, Mei 2015). JSON Web Signature. Format pembungkus yang ditandatangani yang hampir semua orang secara informal menyebutnya «JWT»: tiga segmen base64url yang digabungkan oleh titik. JWS mendukung baik bentuk kompak maupun JSON Serialization; JWT hanya menggunakan bentuk kompak.
RFC 7516 (JWE, Mei 2015). JSON Web Encryption. Varian terenkripsi dengan lima segmen (header, kunci terenkripsi, IV, ciphertext, tag autentikasi). Gunakan JWE, bukan JWS, ketika payload harus rahasia, bukan hanya jelas terhadap perusakan.
RFC 7517 (JWK, Mei 2015). JSON Web Key. Representasi JSON dari kunci kriptografis. Endpoint JWKS (/.well-known/jwks.json) menerbitkan JSON Web Key Set, mekanisme modern untuk rotasi kunci tanpa downtime: verifier mencari kunci berdasarkan kid.
RFC 7518 (JWA, Mei 2015). JSON Web Algorithms. Registri pengidentifikasi alg: HS256/384/512 (HMAC), RS256/384/512 (RSASSA-PKCS1-v1_5), ES256/384/512 (ECDSA), PS256/384/512 (RSASSA-PSS), EdDSA (Ed25519/Ed448), dan none (yang sengaja jarang digunakan).
Bypass alg: none (Tim McLean, 2015). RFC 7518 mencantumkan none sebagai nilai algoritma yang valid untuk konteks tidak aman. Verifier naif akan menerima token dengan header ditulis ulang menjadi {"alg":"none"} dan tanda tangan kosong, memungkinkan penyerang memalsukan payload apa pun. Pustaka modern menolak none secara default; spesifikasi sendiri menyatakan verifier «TIDAK BOLEH menerima JWS Tidak Aman secara default».
Serangan kebingungan algoritma HS/RS (Tim McLean, 2015). Jika verifier memilih algoritma dari header token alih-alih menyematkannya, penyerang dapat menulis ulang header menjadi HS256 dan menandatangani token menggunakan kunci publik RSA server sebagai rahasia HMAC. Pustaka melihat HS256, memperlakukan kunci publik RSA yang dikonfigurasi sebagai rahasia simetris, dan tanda tangan diperiksa. Mitigasi: sematkan algoritma yang diharapkan di luar pita; jangan pernah menurunkannya dari token.
CVE-2022-21449 «Psychic Signatures» (Neil Madden, April 2022). Verifier ECDSA Java 15-18 tidak memeriksa bahwa nilai r dan s tanda tangan adalah bukan nol, yang berarti tanda tangan harfiah semua-nol diterima sebagai valid. JWT yang ditandatangani dengan ES256/384/512 pada JVM yang terpengaruh dapat dipalsukan dengan tanda tangan kosong. Ditambal dalam Pembaruan Patch Kritis Oracle April 2022.

Pertanyaan yang lebih sering ditanyakan

Mengapa alat ini tidak memverifikasi tanda tangan?

Verifikasi memerlukan rahasia (HMAC) atau kunci publik (RSA / ECDSA / EdDSA). Menempelkan rahasia HMAC produksi ke situs web apa pun adalah kebocoran kredensial dengan sendirinya, bahkan pada alat yang bersumpah tidak mengirimkan apa pun. Verifikasi termasuk dalam server yang Anda kontrol. Pekerjaan dekoder adalah membuat konten dapat dibaca sehingga Anda dapat melihat apa yang seharusnya diperiksa verifier Anda.

Apakah aman untuk menempelkan token produksi nyata di sini?

Decoding terjadi sepenuhnya di browser Anda. Token tidak dikirim melalui jaringan, ditulis ke log apa pun, atau disimpan di mana pun. Yang mengatakan, JWT sering adalah kredensial: siapa pun yang memegang token akses yang tidak kedaluwarsa dapat bertindak sebagai pengguna. Konvensi komunitas adalah «perlakukan JWT produksi seperti cookie sesi»: lebih suka token tes ketika Anda bisa, dan putar token nyata apa pun yang Anda bagikan di mana pun di luar sesi browser yang mencetaknya.

Di mana saya harus menyimpan JWT di browser?

Dua pola umum masing-masing memiliki trade-off. localStorage nyaman tetapi dapat dibaca oleh serangan XSS yang sukses di halaman. Cookie dengan HttpOnly tidak terlihat oleh JavaScript sehingga XSS tidak dapat membacanya, tetapi mereka membutuhkan SameSite=Strict atau SameSite=Lax untuk menghindari CSRF. Praktik terbaik saat ini: token akses berdurasi singkat dalam variabel JavaScript (memori saja) ditambah token penyegaran berdurasi panjang dalam cookie HttpOnly + Secure + SameSite=Strict yang berskop ke endpoint penyegaran, dirotasi pada setiap penggunaan.

Apa yang dilakukan bidang kid di header?

Itu mengidentifikasi kunci mana yang menandatangani token. Penyedia identitas modern menerbitkan kunci publik mereka di endpoint /.well-known/jwks.json sebagai JWK Set (RFC 7517); verifier mencari kunci yang kid-nya cocok dengan header token. Inilah yang membuat rotasi kunci tanpa downtime mungkin: baik kunci lama maupun baru dapat berada di JWKS selama masa tenggang.

Bisakah saya mencabut JWT setelah diterbitkan?

Tidak secara native. JWT yang ditandatangani valid sampai klaim exp-nya; ketanpa-statusan itu adalah properti utama format. Solusi: jaga token akses tetap singkat (5-15 menit) dipasangkan dengan token penyegaran yang dapat dicabut; pertahankan daftar penolakan sisi server dari nilai jti yang dicabut; rotasi kunci penandatanganan (yang membatalkan setiap token yang belum diselesaikan yang ditandatangani dengannya). Setiap opsi memperkenalkan kembali beberapa statefulness; itulah trade-nya.

Apakah mendekode token sama dengan mendekripsikannya?

Tidak. Decoding membalikkan base64url kembali ke JSON: siapa pun bisa melakukannya, dan itulah intinya. Dekripsi memerlukan kunci dan hanya berlaku untuk JSON Web Encryption (JWE, RFC 7516), yang merupakan varian terenkripsi dari keluarga JOSE. Kebanyakan token yang Anda lihat di alam liar adalah JWS (ditandatangani tetapi tidak dienkripsi), jadi decoding cukup untuk membacanya.