JWT Çözücü
JWT başlığını ve taleplerini çözün; token sahteciliğine yol açan algoritma ve başlık oyunlarına karşı uyarı alın, yeni token'lar imzalayın ve HS, RS, PS ile ES imzalarını tarayıcınızda doğrulayın.
İlgili araçlar
- Kodlayıcı / ÇözücüBase64, URL'ler ve HTML varlıklarını kodlayıp çözün, sayı tabanlarını dönüştürün.
- JSON AraçlarıJSON'u biçimlendirin, küçültün, onarın ve tam hata konumlarıyla doğrulayın; ağaç görünümünde gezin ve JSON, CSV ile YAML arasında dönüştürün.
- Hash OluşturucuMetni ya da bir dosyayı MD5, SHA-1, SHA-2, SHA-3 veya HMAC ile hash'leyin.
Bu araç hakkında
JWT Çözücü, kompakt bir token'ı üç base64url parçasına ayırır, başlığı ve yükü UTF-8 JSON olarak çözer (RFC 7519) ve zaman iddialarını - exp, nbf, iat ve auth_time - UTC değerleriyle listeler. Başlık, kabul edilmemesi gereken token'ların kabul edilmesini sağlayan hileler için okunur: alg “none”, düzenleyenin RSA veya ECDSA ile imzaladığı yerde bir HMAC algoritması (saldırgan, HMAC gizli anahtarı olarak genel anahtarı kullanıp yeniden imzalar), doğrulayıcıyı gönderenin seçtiği bir anahtara yönlendiren jku, x5u, jwk ve x5c, buradaki hiçbir doğrulayıcının uygulamadığı crit parametreleri, eksik bir kid ve bir yıldan uzak bir exp. jku veya x5u URL'si adıyla anılır, hiçbir zaman getirilmez. İmzayı sayfa içinde doğrulayabilir: paylaşılan bir gizli anahtara karşı HS256, HS384 ve HS512; bir PEM genel anahtarına, bir JWK'ye ya da bütün bir JWKS'ye karşı 256, 384 ve 512 varyantlarıyla RS, PS ve ES - JWKS'de anahtar, token'ın kid değerine göre seçilir (RFC 7518). Aynı algoritmalar imzalayabilir de: birini seçin, başlığı ve yükü düzenleyin, gizli anahtarı veya bir PKCS#8 özel anahtarını verin; token, sayfa içinde Web Crypto ile oluşturulur. Geçerlilik bitişi cihazınızın saatiyle karşılaştırılır; bu yüzden “süresi dolmuş” notu ancak o saat kadar doğrudur. Araç bir JWKS URL'sini getirmez - kümenin yapıştırılması gerekir - ve sizin yerinize iss, aud ya da sub kontrolü yapmaz. Beş parçalı bir JWE, tahmin edilmek yerine reddedilir; çünkü şifrelenmiş bir token, şifre çözme anahtarı olmadan okunamaz.
Token, HS gizli anahtarı ve açık ile özel anahtarlar sayfada kalır: XGM API'sine gönderilmez ve URL'ye hiçbir zaman yazılmaz; bu yüzden paylaştığınız bağlantı yalnızca aracı taşır, yapıştırdıklarınızı taşımaz. Çözümleme atob ve TextDecoder ile yapılır; imzalama ve doğrulamanın ikisi de Web Crypto kullanır - ham HMAC gizli anahtarı, PEM ya da JWK için crypto.subtle.importKey, ardından HMAC, RSASSA-PKCS1-v1_5, RSA-PSS ve ECDSA için crypto.subtle.sign veya crypto.subtle.verify. Yapıştırılan bir JWKS, token'ın kid değeriyle burada, sayfanın içinde eşleştirilir; hiçbir JWKS adresi çekilmez. Uyarılar da aynı şekilde token'ın kendi header ve claim'lerinden okunur: jku veya x5u header'ı adıyla belirtilir ama asla izlenmez ve yazdığınız gizli anahtar, RFC 7518'in istediği uzunluğa karşı sayfadan çıkılmadan ölçülür. JSON ve Markdown dışa aktarımları tarayıcıda oluşturulup indirilir, local storage'a hiçbir şey yazılmaz ve sekmeyi kapatmak girdiğiniz her şeyi siler.
Nasıl kullanılır
- JWT Çözücü aracını açın.
- İncelemek istediğiniz girdiyi yapıştırın veya yazın.
- Tarayıcınızda hesaplanan sonucu okuyun; girdi XGM'e gönderilmez.
- Çıktıyı yalnızca doğru göründüğünü kontrol ettikten sonra kopyalayın.
- Daha geniş bir teşhis görünümü gerekiyorsa ilgili XGM araçlarını kullanın.
SSS
Bu araç gerçekte hangi algoritmaları doğrulayabiliyor?
Paylaşılan bir gizli anahtarla HMAC ailesi HS256, HS384 ve HS512 ile RFC 7518'in açık anahtar aileleri: RSASSA-PKCS1-v1_5 olarak RS256/384/512, bayt cinsinden özet uzunluğuna eşit tuz uzunluğuyla RSA-PSS olarak PS256/384/512 ve P-256, P-384 ile P-521 üzerinde ECDSA olarak ES256, ES384 ve ES512. EdDSA dahil diğer her şey çözülür ancak doğrulama için desteklenmiyor olarak bildirilir. Başlığında alg “none” yazan bir token kritik olarak işaretlenir ve doğrulanamaz, çünkü doğrulanacak bir şey yoktur.
HS256 gizli anahtarım doğru ama imza eşleşmiyor. Neden?
Varsayılan olarak gizli anahtar, tam yazdığınız hâliyle ham UTF-8 baytları olarak kullanılır. Birçok sağlayıcı gizli anahtarı base64 ya da base64url kodlu saklar, dolayısıyla gerçek anahtar yazdırılabilir dizgi değil, çözülmüş baytlardır - bu durumda “Gizli anahtar base64url kodlu” seçeneğini işaretleyin. Gizli anahtarla birlikte kopyalanan sondaki boşluklar veya bir satır sonu da baytları, dolayısıyla HMAC'i değiştirir (RFC 2104).
Araç token'ın süresinin dolduğunu söylüyor ama API'm onu hâlâ kabul ediyor.
exp ve nbf, sağlayıcının saatine ya da bir zaman sunucusuna değil, başında oturduğunuz makinenin saatine göre karşılaştırılan sayısal saniyelerdir. Çoğu sunucu kütüphanesi ayrıca exp ve nbf çevresinde birkaç saniyelik bir tolerans tanır, dolayısıyla sınırı henüz geçmiş bir belirteç orada hâlâ geçerli sayılabilir. iat beş dakikadan fazla gelecekteyse araç ayrı bir uyarı verir; bu genellikle belirtecin değil, sağlayıcının saatinin yanlış olduğu anlamına gelir.
Bir JWKS yapıştırabilir miyim ve anahtarım neden reddediliyor?
Tek bir JWK ya da tüm bir JWKS nesnesi yapıştırabilirsiniz. JSON bir “keys” dizisi içerdiğinde, kid değeri token’ın header'ıyla eşleşen anahtar kullanılır; hiçbir anahtar o kid değerini taşımıyorsa araç bunu söyler ve bulduğu kid'leri belirtir - ilk anahtara geri düşüp güvenemeyeceğiniz bir sonuç bildirmez. kid'i olmayan bir token yalnızca küme tek bir anahtar ya da algoritmaya uygun türde tek bir anahtar içerdiğinde eşleştirilir; aksi hâlde kastettiğiniz tek anahtarı yapıştırmanız istenir. Hiçbir JWKS URL'si çağrılmaz - kümenin yapıştırılması gerekir, çünkü ihraççının uç noktası bu sayfadan gelen kaynaklar arası bir isteği reddederdi. PEM biçiminde yalnızca bir SPKI açık anahtarı (-----BEGIN PUBLIC KEY-----) kabul edilir; sertifikalar ve özel anahtarlar kabul edilmez. Eğri header'dan alınır, bu yüzden P-384 anahtarıyla kullanılan bir ES256 header'ı doğrulamada değil içe aktarmada başarısız olur.
Claim'lerin üstündeki uyarılar ne anlama geliyor?
Bunlar, token'ların taklit edilmesine yol açan header ve claim sorunlarıdır; önem sırasına göre ve alg “none” her zaman en başta olacak şekilde sıralanır. Kritik: alg “none” ya da alg'ın hiç bulunmaması, boş imza ve doğrulayıcıya gönderenin seçtiği bir anahtarı çekmesini veya ona güvenmesini söyleyen jku, x5u, jwk ve x5c header'ları - anahtarlarınızı sabitleyin ve bu header'ları yok sayın. Uyarı: HS algoritması, çünkü algoritmayı token'ın içinden okuyan bir doğrulayıcıya, açık anahtar gizli anahtar olarak kullanılıp HS256 ile yeniden imzalanmış bir RS256 token'ı verilebilir; hash'ten kısa bir HMAC gizli anahtarı, ki RFC 7518 §3.2 bunu yasaklar; asimetrik bir algoritmada kid'in bulunmaması; crit parametreleri, ki RFC 7515'e göre bunları uygulamayan bir doğrulayıcı token'ı reddetmelidir; exp'in bulunmaması ya da bir yıldan uzağa düşmesi. Puan yoktur - bu bir listedir ve geçerli olmayanlar gösterilmez.
Burada token oluşturabilir miyim ve anahtar güvende mi?
Evet. “Encode and sign” bölümüne geçin, HS256/384/512, RS256/384/512, PS256/384/512 veya ES256/384/512 arasından birini seçin, header ve payload JSON'unu düzenleyin ve paylaşılan gizli anahtarı ya da bir PKCS#8 özel anahtarını (-----BEGIN PRIVATE KEY-----) veya özel bir JWK'yı verin. Token tarayıcınızda crypto.subtle.sign ile oluşturulur: anahtar hiçbir zaman yüklenmez, URL'ye yazılmaz ve saklanmaz. Header ve payload imzalamadan önce sıkışık biçimde yeniden serileştirilir, çünkü bir JWT tam olarak imzalanan baytları taşır; dolayısıyla düzenleyicideki boşluklar imzalama girdisinin parçası olamaz. Sizin için hiçbir şey eklenmez - ne iat ne exp - böylece token tam olarak yazdığınız iddiaları içerir. PKCS#1 veya SEC1 anahtarı (-----BEGIN RSA PRIVATE KEY-----), Web Crypto yalnızca PKCS#8 içe aktardığı için, onu dönüştüren openssl komutuyla birlikte reddedilir.
Payload, belirteci elinde tutan kişiden gizli mi?
Hayır. İmzalı bir JWT şifrelenmiş değil, base64url ile kodlanmıştır: token'a sahip olan herkes talepleri tam olarak bu sayfanın okuduğu gibi okur ve imza yalnızca taleplerin değiştirilmediğini kanıtlar. Bir talep adı parola, gizli anahtar, kart numarası ya da benzeri bir şeye benzediğinde araç uyarı verir, çünkü bu değerler fiilen açık hâldedir. İçerik gizli kalmak zorundaysa bir JWE kullanın ya da veriyi opak bir referansın arkasında sunucu tarafında tutun.