JWT'nin üç parçalı yapısını, tipik kullanım senaryolarını, yaygın güvenlik risklerini ve tarayıcı tabanlı çözücü araçlarının gerçek kısıtlarını dürüst bir bakışla öğrenin.
JSON Web Token (JWT), taraflar arasında güvenli şekilde bilgi taşımak için tasarlanmış açık bir standarttır (RFC 7519). Modern web uygulamalarında en çok kimlik doğrulama ve yetkilendirme akışlarında karşımıza çıkar. Bir kullanıcı giriş yaptığında sunucu bir JWT üretir; sonraki isteklerde tarayıcı bu token'ı taşır ve sunucu her seferinde imzayı doğrulayarak kullanıcıyı tanır.
Bu rehberde JWT'nin yapısını, tipik kullanım senaryolarını, güvenlik risklerini ve doğrulama araçlarını dürüst bir bakışla ele alacağız. Özellikle imza doğrulama kısmındaki yaygın hataları ve tarayıcı tabanlı çözücü araçlarının gerçek kısıtlarını açıklayacağız.
JWT'nin üç parçası: Header, Payload, Signature
Bir JWT üç bölümden oluşur ve bu bölümler nokta karakteriyle ayrılır: xxxxx.yyyyy.zzzzz. Her bölüm Base64URL ile kodlanmıştır — dikkat: bu şifreleme değil, sadece kodlamadır. Herkes bir JWT'yi çözüp içindeki bilgileri okuyabilir.
Header genellikle token türünü ve imza algoritmasını içerir: {"alg":"HS256","typ":"JWT"}. Payload asıl veriyi (claim'leri) barındırır — kullanıcı kimliği, roller, son kullanma tarihi (exp), verildiği zaman (iat), verici (iss) ve alıcı (aud) gibi standart alanlar buradadır. Signature ise header ve payload'ın gizli bir anahtarla imzalanmış halidir; token'ın değiştirilmediğini kanıtlar.
Bu üç parçanın ayrımı kritiktir: payload'a hassas veri (parola, kredi kartı numarası, TC kimlik) koymayın, çünkü herhangi biri bunu çözüp okuyabilir. Payload sadece kimlik ve yetki bilgileri için uygundur.
JWT nasıl çalışır? Tipik akış
Standart bir kimlik doğrulama akışı şöyle işler: kullanıcı e-posta ve şifreyle giriş yapar; sunucu bilgileri doğrular ve bir JWT üretip yanıtta döner; istemci bu token'ı yerel depolamada saklar (localStorage veya güvenli httpOnly cookie); sonraki her API çağrısında token Authorization: Bearer <token> başlığı içinde gönderilir; sunucu her istekte imzayı doğrular ve exp alanının süresinin dolup dolmadığını kontrol eder.
Bu akışın en büyük avantajı sunucunun oturum durumu tutmak zorunda kalmamasıdır (stateless). Ancak bu aynı zamanda bir dezavantaj: sunucu tarafında geçici olarak bir token'ı iptal etmek zordur, süresi dolana kadar geçerli kalır. Bu yüzden kısa ömürlü token + refresh token deseni tercih edilir.
Nerede kullanılır?
JWT'nin en yaygın kullanım alanları şunlardır:
- API kimlik doğrulama: Mobil uygulamalar ve SPA'lar için REST veya GraphQL API'lerine erişim.
- Tek oturum açma (SSO): Farklı alt alan adları veya bağlı hizmetler arasında kullanıcının aynı kimliği taşıması.
- Mikroservisler arası kimlik doğrulama: Servisler arasında güvenli mesaj alışverişi ve kimlik doğrulama.
- OpenID Connect (OIDC): OAuth 2.0 üzerine inşa edilmiş modern kimlik protokollerinde kimlik token'ı olarak.
- E-posta doğrulama ve parola sıfırlama: Kısa ömürlü, tek kullanımlık işlem token'ları.
Güvenlik riskleri ve yaygın hatalar
JWT güçlü bir araçtır ama yanlış kullanıldığında ciddi güvenlik açıkları doğurur. En sık karşılaşılan hatalar şunlardır:
1. "alg: none" saldırısı. Bazı eski JWT kütüphaneleri, header'da "alg":"none" yazılıysa imza doğrulamayı atlıyordu. Saldırgan payload'ı istediği gibi değiştirip imzayı silerek yönetici gibi giriş yapabilirdi. Modern kütüphaneler bu algoritmayı reddeder, ancak eski sistemlerde hâlâ bir risk olabilir.
2. Zayıf gizli anahtar. HS256 algoritmasında imza, paylaşılan bir gizli anahtarla üretilir. Anahtar kısa veya tahmin edilebilir (örneğin "secret", "123456") olursa saldırgan brute-force ile anahtarı bulabilir ve kendi token'larını üretir. Anahtarın en az 256-bit (32 byte) rastgele değer olması gerekir.
3. Uzun süre geçerli token'lar. exp alanının uzak bir tarih olması, çalınan token'ın uzun süre kötüye kullanılmasına neden olur. Kısa ömürlü access token (15 dakika - 1 saat) ile uzun ömürlü refresh token deseni daha güvenlidir.
4. Payload'da hassas veri. Payload şifrelenmemiştir, sadece kodlanmıştır. Kullanıcı şifresi, TC kimlik numarası, tam kredi kartı bilgisi payload'a asla konmamalıdır.
5. Algoritma karışıklığı. Sunucu RS256 (asimetrik) beklerken saldırgan HS256 (simetrik) ile imzalanmış bir token gönderirse ve doğrulama kütüphanesi doğru yapılandırılmamışsa, saldırgan public key'i secret olarak kullanıp geçerli görünen bir token üretebilir. Kütüphanenizin alg alanını whitelist ile sınırladığından emin olun.
Yaygın imza algoritmaları
HS256 (HMAC-SHA256) simetrik bir algoritmadır; imzalayan ve doğrulayan aynı gizli anahtarı paylaşır. Hızlıdır ve tek sunucu senaryoları için uygundur. RS256 (RSA-SHA256) asimetriktir; özel anahtarla imzalanır, herkese açık anahtarla doğrulanır. Birden çok servis token'ı doğrulayacaksa RS256 daha uygundur çünkü gizli anahtarı paylaşmanız gerekmez. ES256 (ECDSA-SHA256) da asimetriktir, RS256'ya göre daha küçük imza üretir ve mobil ile IoT için tercih edilir.
"alg":"none" algoritması standartta tanımlı olsa da üretim ortamında asla kullanılmamalıdır. Bazı test senaryoları dışında değeri yoktur.
JWT çözücü araçları ve gerçek kısıtlar
İnternet üzerinde birçok JWT decoder aracı bulunur — Toolmatico'daki JWT Çözücü da bunlardan biridir. Bu tür tarayıcı tabanlı araçlar token'ın header ve payload kısmını Base64URL'den çözerek okunabilir hale getirir; exp alanı varsa süre bitiş durumunu da özet olarak gösterir. Toolmatico'nun aracı HS256, RS256, ES256, PS256 ve EdDSA gibi tüm yaygın algoritmalarla imzalanmış token'ları görüntüleyebilir, çünkü decode işlemi algoritmadan bağımsızdır — Base64URL çözümü her token için aynı şekilde çalışır.
Önemli teknik sınır: Toolmatico'nun JWT Çözücüsü imza doğrulaması yapmaz. Bu bilinçli bir tasarım tercihidir: profesyonel bir geliştirici iş akışında imza doğrulama, gizli anahtara veya public key'e sahip olan sunucu tarafında yapılır. Tarayıcı tabanlı bir görüntüleyici bu güvenlik kararının yerine geçemez. Manipüle edilmiş, imzası sizin sunucunuz tarafından üretilmemiş bir JWT bile decode edildiğinde "geçerli görünen" bir içerikle karşınıza çıkabilir. Bu yüzden üretim ortamı güvenlik kararlarınızı asla bir görüntüleyici aracının çıktısına dayandırmayın.
Toolmatico'nun aracında token tamamen tarayıcınızda çözülür — sunucuya gönderilmez. Yine de üretim ortamından gelen gerçek token'ları herhangi bir üçüncü taraf online araca yapıştırmadan önce iki kez düşünün, çünkü kimlik bilgileri içerir ve tarayıcı geçmişi, log veya kopyala-yapıştır kanalları ile sızabilir. Sunucu tarafında imza doğrulama için dilinize uygun bir JWT kütüphanesi kullanın: Node.js'de jsonwebtoken veya jose, .NET'te System.IdentityModel.Tokens.Jwt, Python'da PyJWT, Java'da jjwt. Test aşamasında hızlı bir imza doğrulaması gerekiyorsa jwt.io (Auth0) gibi araçlar hem decode hem signature verify seçeneği sunar.
Pratik öneriler
Uygulamalarınızda JWT kullanacaksanız şu ilkeleri gözetin: kısa ömürlü access token (15 dakika - 1 saat) ile uzun ömürlü refresh token deseni kullanın; HS256 için en az 256-bit rastgele gizli anahtar üretin ve bunu kaynak koda gömmeyin, ortam değişkeninden okuyun; payload'a asla parola, tam kredi kartı numarası veya benzeri hassas veri koymayın; kütüphanenizin alg alanını doğrulamada whitelist ile sınırladığından emin olun; iptal edilebilirlik gerekiyorsa token'a bir jti (JWT ID) ekleyip sunucu tarafında bir kara liste tutun.
JWT, doğru kullanıldığında modern kimlik doğrulama için mükemmel bir araçtır. Ancak şifreleme değil kodlama olduğunu, imza doğrulamanın kütüphane yanlış yapılandırıldığında atlanabildiğini ve tarayıcıdaki çözücülerin sadece gösterim aracı olduğunu unutmayın. Güvenli bir JWT kullanımı; doğru algoritma seçimi, kısa ömürlü token'lar, güçlü gizli anahtar ve doğrulama katmanında dikkatli bir kütüphane yapılandırması gerektirir.