JWT Çözücü

Bir JSON Web Token'ın header ve payload bölümlerini base64url'den çözer, standart claim'leri okunabilir hâle getirir. Çözme tamamen tarayıcınızda yapılır — token sunucuya gönderilmez. İmza doğrulanmaz; bunun için gizli anahtar gerekir.

Son güncelleme:

Girdi
header.payload.signature biçiminde bir token yapıştırın. Token sunucuya gitmez.

Çözülmüş Token

Header
{ "alg": "HS256", "typ": "JWT" }
Payload
{ "sub": "1234567890", "name": "John Doe", "iat": 1516239022 }
İmza
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

İmza yalnızca ham hâliyle gösterilir; doğrulanmaz. İmza doğrulaması için gizli anahtar (HMAC) veya açık anahtar (RSA/ECDSA) gerekir.

Bu çözücü ne zaman gerekir

Bir 401'in nedenini ayıklarken

"Unauthorized" cevabı nedenini söylemez: token süresi mi doldu, aud mu uyuşmadı, imza mı bozuk? Payload'ı açıp exp, aud ve iss değerlerine bakmak, üç şüpheliden ikisini birkaç saniyede eler.

Kimlik sağlayıcının ne yazdığını görürken

Rol tabanlı yetki çalışmıyorsa ilk soru şudur: rol claim'i token'da gerçekten var mı, adı beklenen mi? Sağlayıcının panelinde göründüğü ile token'a yazılan her zaman aynı değildir; çözüp bakmak tartışmayı bitirir.

Süre davranışını anlamaya çalışırken

Token'ın "erken ölmesi" ya da "ölmesi gerekirken yaşaması" neredeyse her zaman zaman aritmetiği meselesidir. Aşağıdaki örnek en sık görülen senaryoyu sayılarla açıyor.

Çalışılmış örnek: exp değerini dakika dakika okumak

Payload'da şu satır duruyor: exp: 1767225600. Token tam olarak ne zaman ölür ve neden bazen "5 dakika fazla" yaşar?

  1. exp bir NumericDate'tir: saniye cinsinden epoch değeri, milisaniye değil.
  2. 1767225600'ü çevirin: 1 Ocak 2026, 00:00:00 UTC; İstanbul saatiyle 03:00.
  3. 31 Aralık 23:58 UTC'de yapılan istek kabul edilir; iki dakika sonra aynı token 401 alır.
  4. Doğrulayan sunucunun saati 3 dakika ilerideyse token ona 23:57'de ölmüş görünür: buna clock skew denir.
  5. Bu yüzden doğrulayıcılar tolerans tanır; ASP.NET Core JwtBearer'ın varsayılan ClockSkew değeri 5 dakikadır.

"Token süresi doldu ama hâlâ çalışıyor" şikâyeti çoğu zaman bir hata değil, skew toleransının kendisidir: exp + 5 dakikaya kadar kabul varsayılan davranıştır. Tersi de geçerli: saatleri NTP ile hizalanmamış sunucular token'ları erken öldürür. exp'i her zaman UTC'ye çevirip sunucu saatiyle birlikte okuyun.

Sık yapılan dört hata

exp'e milisaniye yazmak

NumericDate saniye ister. JavaScript'in Date.now() çıktısını olduğu gibi yazarsanız 13 haneli değer, token'ı binlerce yıl geçerli yapar ve hiçbir doğrulayıcı süre hatası üretmez. 10 hane görene kadar 1000'e bölün.

Çözebilmeyi doğrulama sanmak

Bu sayfa dahil her araç payload'ı okuyabilir; güven ancak imza doğrulamasından gelir. Doğrulayıcıda kabul edilen algoritmaları açıkça listeleyin: alg alanını token'dan okuyup ona güvenen yapılandırmalar, tarihsel none ve RS256/HS256 karıştırma saldırılarının hedefidir.

Token'ı localStorage'da saklamak

localStorage'a koyan her sayfa, çalışan her script'e de vermiş olur; tek bir XSS açığı oturumu dışarı taşır. HttpOnly + Secure çerez, script'ten okunamadığı için aynı açıkta bile token'ı vermez.

Tam token'ı loglamak

Hata ayıklarken Authorization başlığını olduğu gibi log'a düşürmek, log okuyabilen herkese canlı oturum dağıtmaktır. İz sürmek için jti veya sub yeter; token'ın kendisi asla log satırına girmemelidir.

Bu araçla birlikte kullanılanlar

  • Base64 Kodlayıcı-Çözücü Metni Base64'e kodlayın veya geri çözün. Standart ve URL-güvenli (base64url) varyant; UTF-8 uyumlu, tarayıcıda.
  • Epoch / Unix Timestamp Dönüştürücü Unix epoch zaman damgalarını okunabilir tarihlere çevirin ve geri dönüştürün. Saniye ve milisaniye otomatik algılanır.
  • Kubernetes Kaynak Bütçesi Hesaplayıcısı Pod istekleri ve düğüm boyutuna göre kaç düğüme ihtiyacınız olduğunu, paketleme verimliliğini ve tahmini aylık maliyeti hesaplayın.
  • UUID Üretici Kriptografik olarak güvenli UUID v4 ve zaman-sıralı v7 üretin. Toplu üretim ve biçim seçenekleri.
  • CIDR / Subnet Hesaplayıcısı CIDR notasyonundan ağ adresi, broadcast, subnet maskesi, kullanılabilir host aralığı ve adres tipini hesaplayın.

Sık Sorulan Sorular

Yapıştırdığım token sunucuya gönderiliyor mu?

Hayır. Çözme işlemi tamamen tarayıcınızda, JavaScript ile yapılır; token hiçbir sunucuya gönderilmez ve hiçbir yerde saklanmaz. Sayfayı kapattığınızda hiçbir iz kalmaz.

Bu araç token imzasını doğruluyor mu?

Hayır. Bu araç yalnızca header ve payload bölümlerini base64url'den çözer. İmza doğrulaması, token'ı üreten tarafın gizli anahtarını (HS256 gibi HMAC) veya açık anahtarını (RS256/ES256) gerektirir; bu sırrı bir web aracına vermek güvenli değildir. Doğrulamayı sunucu tarafında, JwtBearer middleware ile yapın.

JWT içindeki veriler şifreli mi?

Hayır. base64url yalnızca bir kodlamadır, şifreleme değil — payload'ı herkes çözebilir. JWT'ye parola, kişisel veri veya gizli bilgi koymayın. Gizlilik gerekiyorsa JWE (şifreli JWT) kullanın ya da hassas veriyi token dışında tutun.

exp, iat ve nbf claim'leri ne anlama gelir?

Üçü de NumericDate'tir: 1 Ocak 1970 UTC'den bu yana geçen saniye sayısı. exp (expiration) token'ın son kullanma anı; iat (issued at) verildiği an; nbf (not before) ise token'ın geçerli sayılmaya başladığı andır. Bu araç üçünü de okunabilir tarihe çevirir ve token'ın süresinin dolup dolmadığını gösterir.

.NET'te bir JWT nasıl doğrulanır?

Microsoft.AspNetCore.Authentication.JwtBearer paketini ekleyip AddAuthentication().AddJwtBearer(...) ile TokenValidationParameters tanımlayın: ValidateIssuer, ValidateAudience, ValidateLifetime ve IssuerSigningKey. Middleware imzayı, vereni ve süreyi sizin yerinize denetler — imzayı elle çözmeyin.

Daha fazlası: Güvenlik ve .NET kimlik doğrulama üzerine teknik yazılar