25 Haz 2026advanced • 11 minjwt · authentication · debugging · securityJWT Çözücü ve Doğrulayıcı

JWT Sorunlarını Token'ı Çözerek Ayıklayın

Çoğu 401 gizemi, token'ı okuduğunuz anda biter: JWT'ler nasıl yapılandırılır, exp/iat/nbf ve alg alanı gerçekte ne anlama gelir, çözmek neden doğrulamak değildir ve iki dakikalık bir çözümlemenin ortaya çıkardığı tekrarlayan hatalar.

Tüm rehberler →•Dönüştürücüyü aç →

Gerekenler

Materyaller

Beklenmedik davranan bir JWT (Authorization başlığından, çerezden veya loglardan)

Araçlar

Omnvert JWT Çözücü

Adım adım

1
Anatomiyi bilin: header.payload.signature
Bir JWT, noktalarla birleştirilmiş üç base64url kodlu bölümden oluşur. Header, token türünü ve imzalama algoritmasını (alg alanı) bildiren küçük bir JSON nesnesidir. Payload, claim'lerden oluşan bir JSON nesnesidir — token kimin için, kim vermiş, ne zaman doluyor. İmza, ilk iki bölüm üzerinden hesaplanır ve değiştirilmediklerini kanıtlar. Kritik nokta: base64url bir kodlamadır, şifreleme değil. Standart (şifrelenmemiş) bir JWT'yi elinde tutan herkes header ve payload'ı hiçbir gizli bilgi olmadan okuyabilir. Çözerek hata ayıklamanın tüm temeli budur — ve JWT claim'lerine asla parola veya hassas kişisel veri koymamanız gerekmesinin nedeni de.
2
Tarayıcıda güvenle çözün
Token'lar birer kimlik bilgisidir, bu yüzden nereye yapıştırdığınız önemlidir. Omnvert JWT çözücüaracı, tarayıcının Web Crypto API'sini kullanarak tamamen istemci tarafında çözer ve doğrular — token hiçbir sunucuya gönderilmez. (Tek isteğe bağlı ağ isteği, siz isterseniz bir JWKS URL'sinden açık anahtarları çekmektir; tamamen çevrimdışı kalmak için bunun yerine JWKS JSON'ını yapıştırabilirsiniz.) Token'ı yapıştırın ve çözülmüş header ile payload'ı yan yana okuyun. Yine de yapıştırılmış bir üretim token'ına ifşaya yakın muamele edin: test kullanıcısına ait token'ları tercih edin ve panolardan, sohbet kayıtlarından geçmiş yüksek yetkili her şeyi rotasyona sokun.
3
Zaman claim'lerini okuyun: exp, iat, nbf
Üç zaman claim'i Unix zaman damgasıdır — 1970'ten bu yana geçen saniye, milisaniye değil. exp token'ın geçerliliğini yitirdiği an; iat verildiği an; nbf ('not before') kullanılabileceği en erken andır. En yaygın JWT hatası düpedüz süresi dolmuş token'dır: exp'i şu anki zamanla karşılaştırın, gizem çoğu zaman orada biter. İkinci en yaygını saat kaymasıdır: token'ı veren sunucunun saati doğrulayan sunucununkinden ilerideyse, taze bir token iat veya nbf değeri birkaç saniye gelecekte olacak şekilde gelir ve 'henüz geçerli değil' diye reddedilir. Doğrulayıcıların genellikle küçük bir tolerans (bir dakika veya altı) tanımasının nedeni budur. İlgili bir tuzak: exp'e milisaniye yazılarak üretilmiş bir token binlerce yıl sonrasına ait bir tarihe çözülür — bir kodun yanlış birim kullandığının açık işaretidir.
4
Kimlik claim'lerini kontrol edin: iss, aud, sub
iss (issuer) token'ı hangi sistemin ürettiğini, aud (audience) hangi sistem için üretildiğini, sub (subject) ise kullanıcıyı veya istemciyi belirtir. Doğrulayıcılar, iss veya aud değeri yapılandırmayla birebir eşleşmeyen token'ları genellikle reddeder — kilit kelime 'birebir'. Üretim ortamına sunulan bir staging token'ı, iss'i staging issuer URL'sini gösterdiği için kalır. aud uyuşmazlığı, tek kimlik sağlayıcının birden çok API'ye hizmet verdiği ve istemcinizin yanlış API için token istediği durumda ortaya çıkar. Issuer URL'lerindeki sondaki eğik çizgi ve http-https farkı klasiktir: 'https://auth.example.com' ile 'https://auth.example.com/' farklı dizelerdir ve katı doğrulayıcılar bunları farklı issuer sayar.
5
alg alanını şüpheyle okuyun
Header'daki alg, imzalama algoritmasını bildirir: HS256 simetrik bir HMAC'tir (tek ortak gizli anahtar hem imzalar hem doğrular); RS256 ve ES256 asimetriktir (özel anahtar imzalar, açık anahtar doğrular). Tarihsel olarak önemli iki tuzak buradadır. Birincisi, 'none' algoritması — standart imzasız token'lara izin verir ve eski ya da yanlış yapılandırılmış kütüphaneler bunları kabul etmiştir; yani saldırgan imzayı söküp claim'leri sahteleyebilirdi. Modern kütüphaneler 'none'ı açıkça etkinleştirilmedikçe reddeder; sizinki de reddetmelidir. İkincisi, HS256/RS256 karışıklığı: kütüphanenin algoritmayı token'ın kendi alg header'ına seçtirdiği savunmasız kurulumlarda saldırgan, RS256'yı açık anahtarla doğrulayan bir sunucuyu hedef alıp HS256'lık bir token üretebilir ve sunucuya o açık anahtarı — herkesin elindeki anahtarı — HMAC gizli anahtarı olarak kullandırabilirdi. Her iki durumda da savunma aynıdır: sunucu beklediği algoritmayı yapılandırmada sabitlemeli ve seçimi asla token'ın header'ına bırakmamalıdır. Hata ayıklama açısından: çözdüğünüz alg, sunucu yapılandırmanızın beklediği değilse hatayı bulmuşsunuz demektir.
6
Çözmenin doğrulamak olmadığını içselleştirin
Çözmek yalnızca base64url'i geri alır — özgünlük hakkında hiçbir şey kanıtlamaz. Herkes istediği claim'lerle bir JWT kurabilir; token'ın gerçekten o issuer'dan değiştirilmeden geldiğini, yalnızca HMAC gizli anahtarıyla veya issuer'ın açık anahtarıyla yapılan imza denetimi ortaya koyar. Yani çözücü bir okuma aracıdır, güven aracı değil: token'ın ne söylediğini incelemek için kullanın, ona inanıp inanmamaya karar vermek için asla. Gizli anahtarı, açık anahtarı veya JWKS'i sağlarsanız Omnvert aracı imzaları yerel olarak da doğrulayabilir — ortamlar arası anahtar uyuşmazlığından şüphelendiğinizde 'bu imza, sunucumun kullandığı anahtara göre gerçekten geçerli mi?' sorusunu yanıtlamak için yararlıdır. Ve 'herkes okuyabilir' gerçeğinin öbür yüzü: token'larınızın payload'ı onu elinde tutan herkese fiilen açıktır; claim'ler asla sır taşımamalıdır.
7
Beş soruluk hızlı teşhisi uygulayın
Token çözülmüşken sırayla yanıtlayın: (1) exp geçmişte mi? Süresi dolmuş token — yenileme (refresh) mantığını inceleyin. (2) iss ve aud, kalan sunucunun beklediğiyle birebir aynı mı? Değilse token yanlış ortamdan gelmiş ya da yanlış API için istenmiştir. (3) alg, sunucunun yapılandırıldığı algoritma mı? Uyuşmazlık, imzalama ve doğrulama yapılandırmalarının ayrıştığı anlamına gelir. (4) nbf/iat hafifçe gelecekte mi? Saat kayması — sunucu saatlerini karşılaştırın ve tolerans ekleyin. (5) Payload, uç noktanın yetkilendirmede kullandığı claim'leri (roller, scope'lar, tenant kimliği) taşıyor mu? Gerekli scope'u eksik olan geçerli bir token, kimlik doğrulama hatası gibi görünen ama aslında yetkilendirme eksiği olan bir 403 üretir. Bu dizi, 'token çalışmıyor' kayıtlarının büyük çoğunluğunu sunucu loglarına dokunmadan çözer.

Uygulamalı bir örnek

Tipik bir erişim token'ının çözülmüş header ve payload'ıjson

123456789101112// header
{ "alg": "RS256", "typ": "JWT", "kid": "key-2026-05" }

// payload
{
  "iss": "https://auth.example.com",
  "aud": "https://api.example.com",
  "sub": "user_18274",
  "iat": 1782300000,
  "exp": 1782303600,
  "scope": "orders:read orders:write"
}

Bu token'ı okuyalım: kid'i 'key-2026-05' olan anahtarla RS256 kullanılarak imzalanmış — sunucunun anahtar kümesinde bu kid artık yoksa, token'da hiçbir sorun olmasa da doğrulama başarısız olur; çözüm, sunucunun önbelleğe alınmış anahtarlarını yenilemektir. Bir saat geçerli (exp eksi iat 3600 saniye). Sipariş okuma ve yazma yetkisi veriyor, başka bir şey vermiyor; dolayısıyla faturalama uç noktasına yapılan bir isteğin 403 döndürmesi doğru davranıştır. Ve auth.example.com tarafından api.example.com için verilmiş — katı audience denetimi yapan başka herhangi bir API'ye sunulursa reddedilir.

Her gerçek token'a kimlik bilgisi muamelesi yapın

Bearer token adı üstündedir: onu taşıyan (bear eden) kimliği doğrulanmış sayılır. Yetkili hesapların üretim token'larını ortak sohbetlere, hata takip sistemlerine veya hata ayıklama oturumunuzun ekran görüntülerine yapıştırmayın — çözülmüş payload'ı göstermek zararsızdır ama üç bölümlü token'ın tamamı exp anına kadar çalışan bir anahtardır. Örnek paylaşmanız gerektiğinde tek kullanımlık bir test hesabının token'ını kullanın ya da yalnızca çözülmüş claim'leri paylaşın.