JWT Token Nedir ve Nasıl Çözümlenir?

JWT, bir sunucunun kullanıcı hakkında imzaladığı, üç parçadan oluşan bir metin; parçaları ayırdığında ortadaki kısım genelde kullanıcı bilgisini okunabilir halde gösterir, ama bu imzanın geçerli olduğu anlamına gelmez.

Özet

Adım adım

Token'ı noktalarından üç parçaya ayır: başlık, veri (payload), imza.
Ortadaki payload kısmını bir JWT çözücüyle decode et, içindeki alanları oku.
"exp" alanına bak, token'ın süresinin dolup dolmadığını buradan anlarsın.
Decode etmenin imzayı doğrulamak olmadığını unutma; bir token'ın gerçekten geçerli olup olmadığını sadece onu üreten sunucu kontrol edebilir.

Neden önemli?

JWT'nin ilk iki parçası şifrelenmiş değildir, yalnızca Base64URL ile kodlanmıştır. Yani token'ı ele geçiren herkes içindeki bilgiyi okuyabilir. Bu yüzden payload'a parola, kart bilgisi ya da kişisel hassas veri koymak ciddi bir tasarım hatasıdır. JWT'yi çözümlemeyi bilmek, hem kendi uygulamanın neyi dışarı sızdırdığını görmeni hem de giriş sorunlarını hızlıca teşhis etmeni sağlar. Gizli tutulması gereken bir bilgi gerçekten token içinde taşınacaksa, imzalı JWT yerine şifrelenmiş bir yapı (JWE) kullanılması gerekir.

Payload'da sık gördüğün alanlar

sub: token'ın ait olduğu kullanıcı veya varlık, genelde bir kimlik numarası.
iss: token'ı üreten taraf.
aud: token'ın hangi hizmet için üretildiği.
iat: token'ın üretildiği an; nbf: token'ın geçerli olmaya başladığı an.
exp: son kullanma anı. Bu ve diğer zaman alanları, 1 Ocak 1970'ten bu yana geçen saniye cinsinden bir sayıdır; okunabilir tarihe çevirmen gerekir.

Sık yapılan hatalar

Sunucu tarafında token'ı sadece decode edip imzayı doğrulamadan içindeki rol bilgisine güvenmek. Payload'ı değiştirmek çok kolaydır.
Başlıktaki alg alanını sorgusuz kabul etmek. Sunucu yalnızca kendi beklediği algoritmayı kabul etmeli, "none" gibi imzasız değerleri reddetmelidir.
Uzun ömürlü token üretip iptal mekanizması kurmamak. Çalınan bir token, süresi dolana kadar kullanılabilir.
Canlı ortamdan alınmış gerçek kullanıcı token'larını nasıl çalıştığını bilmediğin çevrimiçi araçlara yapıştırmak.

Örnek bir senaryo

Bir ön yüz geliştiricisi, kullanıcıların giriş yaptıktan birkaç dakika sonra 401 hatası almaya başladığını fark ediyor. Tarayıcının geliştirici araçlarından isteklerde giden token'ı kopyalayıp çözüyor. exp değerini tarihe çevirince, token'ın üretildikten yalnızca beş dakika sonra sona erdiğini görüyor. Sorun kodda değil, kimlik doğrulama servisinin yapılandırmasındaymış. Bir başka olası neden de sunucu saatinin kayması olabilirdi; iat değeri gelecekte bir zamanı gösteriyorsa ilk bakılacak yer sistem saatidir.

Decode ettikten sonra

Çözümlediğin token'da beklemediğin bir alan ya da hassas bir bilgi görürsen, bunu token'ı üreten ekiple paylaş. Payload'ın küçük ve yalnızca gerekli bilgilerle sınırlı tutulması hem güvenlik hem performans açısından daha iyidir, çünkü token genelde her istekte yeniden gönderilir.