JWT Çözücü

İçindeki claim'leri anlamlandırmak

Bir token çözüldüğünde, yük (payload) çoğunlukla claim adı verilen bir avuç kısa, standartlaştırılmış alandan oluşur. Sürekli karşılaşacaklarınız şunlardır: iss, tokeni oluşturan yayımcıyı adlandırır; sub, hakkında olduğu kullanıcıyı veya konuyu tanımlar; aud, hedef kitleyi — tokenin amaçlandığı API'yi — adlandırır; iat ne zaman yayımlandığını, exp ise ne zaman geçersiz hâle geleceğini kaydeder. İçindeki diğer her şey özeldir: roller, e-posta adresleri, özellik bayrakları, yayımlayan sistemin içine koymaya karar verdiği her ne ise. Zaman claim'leri insanları şaşırtır, çünkü bunlar sade Unix zaman damgalarıdır — 1970'ten bu yana geçen saniyeler — okunabilir bir tarih yerine 1784528768 gibi bir sayıdır; bu yüzden tokenin tüm ömrü, iki sıradan görünen tam sayının içinde saklanır.

Reddedilen bir tokeni hata ayıklamak

Bir API 401 yanıtı verdiğinde ve tokenin doğru olduğundan eminseniz, kısa bir listeyi sırayla kontrol edin. Önce, onu bir Authorization başlığından kopyaladıysanız, önündeki Bearer kelimesini ve boşluğu çıkarın — bunlar üzerinde kaldığı sürece geçerli bir JWT değildir ve çözülmez bile. Sonra exp'i okuyun ve gerçekten gelecekte olduğunu kontrol edin: sayıyı Unix zaman damgası dönüştürücüye yapıştırın; süre dolumunu gerçek bir tarih olarak görürsünüz — çoğu zaman saatler önce ölmüş bir tokeni ortaya çıkarır. Ardından aud ve iss'i çağırdığınız API ile karşılaştırın — staging ortamı için basılmış bir token, üretim tarafından rutin olarak ve doğru şekilde reddedilir. Ve sunucular arasında bir dakikalık saat kayması bile, yeni yayımlanmış bir tokenin henüz geçerli değilmiş gibi görünmesine yeter.

Bu aracın açamadığı tokenler

Bir API'yi koruyan her şey okunabilir bir JWT değildir. Üç yerine noktayla ayrılmış beş parçası olan bir token bir JWE'dir — yalnızca kodlanmış değil, gerçekten şifrelenmiştir — ve ne burada ne başka bir yerde, anahtar olmadan okunabilir hiçbir şey çıkmaz. Ayrıca birçok oturum tokeni, baştan beri JWT olmayan, yalnızca opak rastgele dizelerdir; eyJ gibi bir şeyle başlamıyorsa, muhtemelen çözülecek bir şey yoktur. Gerçekten açılan tokenler için, neye baktığınızı hatırlamak faydalıdır: noktalarla birbirine yapıştırılmış üç blok Base64URL metni. Base64 aracı herhangi bir tek bloğu kendi başına çözer; bu, bir JWT'nin okunabilir kısımlarının baştan beri hiç gizli olmadığını kendi gözlerinizle görmenin güzel bir yoludur.

Bir JWT'yi çözmek size ne söyler, ne söylemez

Bir JWT'nin başlığı ve yükü, yalnızca Base64URL ile kodlanmış JSON'dur — herkes bunları çözüp okuyabilir, herhangi bir sır gerekmez; bu aracın yaptığı tam olarak budur. Yapamadığı şey ise imzayı doğrulamaktır: bunun için, bilerek rastgele bir web sitesine yapıştırmayacağınız türden, sağlayanın gizli veya genel anahtarı gerekir.