JWT Çözücü (JSON Web Token)

Bir JSON Web Token, noktayla ayrılmış üç parçadan oluşur: header.payload.signature. İlk bakışta anlamsız görünen bu uzun karakter dizisi aslında düzenli bir yapıya sahiptir ve her parçanın kendine ait bir görevi vardır. JWT Çözücü tam da bu üç parçayı ayırıp okunabilir hale getirmek için kullanılır.

İlk parça olan header (başlık), token'ın hangi algoritmayla imzalandığını ve türünü belirtir. Örneğin alg alanı HS256 veya RS256 değerini taşır, typ alanı ise genellikle JWT olur. İkinci parça olan payload (yük), asıl verinin bulunduğu yerdir. Kullanıcı kimliği, yetkiler ve zaman bilgileri burada saklanır. Üçüncü parça olan signature (imza) ise token'ın değiştirilmediğini doğrulamak için üretilir.

Header ve payload, base64url adı verilen bir kodlamayla saklanır. Bu, klasik Base64'e çok benzer ama URL'lerde ve HTTP başlıklarında sorun çıkarmayacak şekilde + ve / karakterleri farklı işaretlerle değiştirilir. Base64url ne bir şifreleme ne de sıkıştırmadır, yalnızca metni güvenle taşınabilir bir biçime dönüştüren bir kodlamadır. Bu yüzden bir token'ı çözmek için hiçbir gizli anahtara ihtiyaç duyulmaz.

Bu ayrımı daha iyi kavramak isterseniz Base64 çözme aracımız ile bir metnin nasıl kodlanıp çözüldüğünü deneyebilirsiniz. Çözülen JSON çıktısını daha düzenli okumak için ise JSON düzenleyici işinizi kolaylaştırır. Bir token'ın standardı 7.519 numaralı RFC belgesinde tanımlanmıştır ve tüm modern kimlik doğrulama sistemleri bu yapıyı temel alır.

Payload içindeki her alana claim (iddia) denir. Bazı claim'ler tamamen size özeldir, bazıları ise standart olarak tanımlanmıştır ve tüm sistemlerde aynı anlamı taşır. Bu standart alanları tanımak, bir token'ı çözdüğünüzde ne gördüğünüzü anlamanızı sağlar.

En sık karşılaşacağınız standart claim'ler şunlardır:

Zamanla ilgili üç alan olan exp, iat ve nbf, Unix zaman damgası biçiminde tutulur. Yani 1 Ocak 1970 tarihinden bu yana geçen saniye sayısıdır. Ham haliyle bir insanın bu sayıyı okuması zordur, bu yüzden JWT Çözücü bu değerleri otomatik olarak okunabilir tarih ve saate çevirir.

Standart claim'lerin dışında kalan her şey özel claim sayılır. Örneğin bir role alanıyla kullanıcının yetkisini, bir email alanıyla adresini taşıyabilirsiniz. Payload'a çok fazla veri koymaktan kaçınmak iyi bir alışkanlıktır, çünkü token'lar her istekte gönderilir ve büyüdükçe ağ trafiğini artırır. Genel bir yaklaşım olarak payload boyutunu 8 kilobaytın altında tutmak istekleri hafif ve hızlı tutar.

Bir token'ı çözmek ile doğrulamak çok farklı iki işlemdir ve bu ayrımı anlamamak ciddi güvenlik hatalarına yol açar. JWT Çözücü yalnızca çözme işlemi yapar, doğrulama yapmaz. Bunun neden böyle olduğunu ve sizin için ne anlama geldiğini bilmek önemlidir.

Çözme, header ve payload parçalarını base64url'den geri açıp okunabilir JSON'a dönüştürmektir. Bu işlem hiçbir gizli anahtar gerektirmez, çünkü içerik zaten herkese açık bir kodlamayla saklanır. Elinde token olan herkes, tarayıcısında saniyeler içinde payload'ı okuyabilir. İşte bu yüzden bir token'ın içine parola gibi hassas bilgiler asla konmamalıdır.

Doğrulama ise bambaşka bir iştir. Bir sunucu token'ın imzasını, kendi elindeki gizli anahtar veya açık anahtarla yeniden hesaplar ve token'daki imzayla karşılaştırır. İmza tutuyorsa token'ın içeriği yolda değiştirilmemiş ve güvenilir kaynaktan geldiği kanıtlanmış demektir. Bu işlem sunucu tarafında, gizli anahtarın bulunduğu ortamda yapılır.

Buradan çıkan en kritik kural şudur: çözülmüş bir token'a asla güvenmeyin. Bir token'ın payload'ında role: admin yazması, o kullanıcının gerçekten yönetici olduğu anlamına gelmez. Herhangi biri sahte bir token uydurup içine istediğini yazabilir, ama geçerli bir imza üretemez. Güven yalnızca imza doğrulamasından gelir. Bu araç bir hata ayıklama ve öğrenme aracıdır, bir güvenlik kapısı değildir.

Bir API çağrısı beklenmedik şekilde 401 veya 403 hatası döndürdüğünde, sorunun kaynağını bulmanın en hızlı yolu token'ın içine bakmaktır. JWT Çözücü bu noktada devreye girer ve tahmin yürütmek yerine gerçek verileri görmenizi sağlar.

En yaygın neden süresi dolmuş token'dır. exp alanı geçmiş bir zamanı gösteriyorsa, token artık geçersizdir ve yeni bir tane almanız gerekir. Aracın çevirdiği okunabilir tarih sayesinde, token'ın ne zaman geçersiz olduğunu anında görürsünüz. Genellikle erişim token'ları kısa ömürlüdür ve 15 dakika gibi sürelerle sınırlanır.

İkinci sık karşılaşılan sorun yanlış audience'dır. aud alanı, token'ın hangi servis için üretildiğini belirtir. A servisi için alınmış bir token'ı B servisine gönderirseniz, B doğru şekilde reddedecektir. Çözülmüş payload'da bu alanı kontrol etmek dakikalarca sürecek bir aramayı bitirir.

Üçüncü ve daha sinsi bir sorun saat kayması'dır (clock skew). Token üreten sunucu ile doğrulayan sunucunun saatleri birbirinden birkaç saniye farklıysa, henüz geçerli olması gereken bir token nbf yüzünden reddedilebilir. Sistemler genellikle bu farkı tolere etmek için küçük bir pay bırakır, ama sunucu saatlerini eşitlemek kalıcı çözümdür.

Hata ayıklarken izlenebilecek pratik bir sıra şudur:

1. Token'ı araca yapıştırın ve payload'ı okuyun.
2. exp değerinin gelecekte olduğunu doğrulayın.
3. aud ve iss alanlarının beklediğiniz değerlerle eşleştiğini kontrol edin.
4. Sorun sürüyorsa imza doğrulamasını sunucu tarafında inceleyin.

Bir token çoğu zaman bir kullanıcının oturumunu temsil eder, dolayısıyla onu nereye yapıştırdığınız önemlidir. JWT Çözücü, tüm çözme işlemini tamamen tarayıcınızın içinde yapar. Yapıştırdığınız token hiçbir sunucuya gönderilmez, kaydedilmez ve ağ üzerinden hiçbir yere iletilmez.

Bu tasarım bilinçli bir tercihtir. Çözme işlemi zaten hiçbir gizli anahtar gerektirmediği için, sunucuya gitmesine hiçbir teknik gereksinim yoktur. Base64url çözme ve JSON ayrıştırma, modern tarayıcıların rahatça yaptığı hafif işlemlerdir. Böylece aracı çevrimdışıyken bile kullanabilirsiniz ve verileriniz cihazınızdan hiç çıkmaz.

Yine de altını çizmek gerekir: bir aracın yerel çalışması, gerçek üretim token'larını rastgele yerlere yapıştırma alışkanlığını haklı çıkarmaz. Geliştirme ve öğrenme sırasında sahte veya test token'ları kullanmak en sağlıklı yaklaşımdır. Gerçek bir kullanıcıya ait aktif bir token'ı, kaynağına güvenmediğiniz herhangi bir çevrimiçi araca yapıştırmak riskli bir alışkanlıktır.

Özetle bu aracın güvenlik yaklaşımı üç ilkeye dayanır:

• Veri cihazınızda işlenir, dışarı çıkmaz.
• Çözme için hiçbir gizli anahtar istenmez.
• Sonuç yalnızca gösterim amaçlıdır, hiçbir yere kaydedilmez.

Bu ilkeler sayesinde token yapısını incelemek, claim'leri okumak ve hata ayıklamak hem hızlı hem de gönül rahatlığıyla yapılabilir bir işe dönüşür.

Bir token'ı çözdüğünüzde header içindeki alg alanı gözünüze çarpar. Bu alan token'ın hangi algoritmayla imzalandığını söyler ve en çok karşılaşacağınız iki değer HS256 ile RS256'dır. İkisi arasındaki farkı bilmek, sistemin nasıl çalıştığını anlamanıza yardımcı olur.

HS256, simetrik bir yöntemdir. Hem imzalayan hem de doğrulayan taraf aynı gizli anahtarı paylaşır. Kurulumu basittir ve tek bir servisin hem token üretip hem doğruladığı durumlar için idealdir. Dezavantajı, gizli anahtarı birden fazla tarafla paylaşmanız gerektiğinde ortaya çıkar; anahtarı bilen herkes geçerli token üretebilir.

RS256 ise asimetrik çalışır. Token'ı imzalamak için özel anahtar, doğrulamak için ise açık anahtar kullanılır. Bu ayrım büyük bir esneklik sağlar: özel anahtarı yalnızca kimlik sağlayıcı saklar, açık anahtar ise onu isteyen tüm servislere güvenle dağıtılabilir. Çok sayıda servisin aynı sağlayıcıyı kullandığı büyük sistemlerde tercih edilen yöntem budur.

Aşağıdaki karşılaştırma iki yaklaşımı özetler:

JWT Çözücü her iki durumda da header ve payload'ı sorunsuz gösterir, çünkü çözme işlemi algoritmadan bağımsızdır. İmzanın gerçekten geçerli olup olmadığını anlamaksa yalnızca ilgili anahtarla, sunucu tarafında yapılan doğrulamayla mümkündür.