- Konu sahibi
- #1
JWT doğrulamasında kontrol edilen alanlar
JWT doğrulamasında yalnızca token içindeki alanların okunması yeterli değildir. Önce beklenen token biçimi, izinli algoritma ve güvenilir anahtar seçilir; imza/MAC doğrulandıktan sonra
iss, aud, exp ve gerekiyorsa nbf, sub gibi talepler kontrol edilir. Kimlik doğrulama kararı, imza ve zorunlu alanların tümü geçerli olmadan verilmemelidir.JWT bölümleri ve güvenilirlik sırası
Burada imzalı compact JWS biçimindeki JWT doğrulanır: header, payload ve signature olmak üzere üç bölüm vardır. Şifreli veya iç içe tokenlar farklı işleme profilleri gerektirir; her JWT’yi üç parçalı varsaymayın. Header ile payload Base64URL biçiminde okunabilir; ancak okunabilir olmaları doğru oldukları anlamına gelmez. Payload içindeki hiçbir değer imza doğrulanmadan güvenilir kabul edilmemelidir.
İlk kontrol, tokenın beklenen yapıda olup olmadığıdır. Ardından doğrulama kodu, kendi yapılandırmasında izin verilen algoritmalardan birini beklemeli ve imzayı sunucu tarafındaki doğru anahtarla doğrulamalıdır. Tokenın header bölümündeki
alg değeri, sunucunun hangi algoritmaya izin vereceğini tek başına belirlememelidir. Aksi durumda algoritma karışıklığı veya yanlış anahtar seçimi riski doğar.Hangi alanlar kontrol edilir?
Aşağıdaki kontrollerin bazıları JWT standardının tanımladığı kayıtlı claim alanlarıdır; hangilerinin zorunlu olduğu ise uygulamanın güvenlik politikasına bağlıdır.
Bu kontrollerin yanında
iat (oluşturulma zamanı) ve jti (token kimliği) uygulamaya göre kontrol edilebilir. iat gelecekte olamayacak şekilde sınırlandırılabilir; jti ise iptal listesi, tekrar oynatma önleme veya oturum takibi için kullanılabilir. typ gibi header alanları da beklenen token türünü sınırlamak için kullanılabilir, fakat her uygulamada zorunlu değildir.Varsayımsal bir doğrulama örneği
Bir API, yalnızca kendi kimlik sağlayıcısından gelen ve bu API için üretilmiş erişim tokenlarını kabul etsin. Aşağıdaki JSON yalnızca kurgu payload alanlarını gösterir; bir imza veya doğrulanabilir JWT içermez:
Kod:
{
"iss": "https://login.example.com",
"aud": "api.example.com",
"sub": "user-482",
"exp": 1900000000,
"nbf": 1899996400,
"scope": "orders:read"
}| Alan | Kontrol | Geçersizse | Not |
|---|---|---|---|
| alg | İzin verilen algoritmayla eşleşiyor mu? | Token reddedilir | Header değeri allowlist yerine geçmez |
| iss | Beklenen yayıncıyla tam eşleşiyor mu? | Token reddedilir | Güvenilen kimlik sağlayıcıyı sınırlar |
| aud | Bu API veya istemci hedef kitle olarak bulunuyor mu? | Token reddedilir | Dizi veya tekil değer biçimi desteklenmelidir |
| exp | Süre dolmuş mu? | Token reddedilir | NumericDate: Unixepoch başlangıcından itibaren saniye; milisaniye değildir |
| nbf | Kullanım zamanı henüz gelmiş mi? | Token reddedilir | Saat farkı için sınırlı tolerans politikası gerekir |
| sub | Kullanıcı veya özne kimliği mevcut ve beklenen biçimde mi? | İşlem reddedilir | Yetki kararında bağlamına uygun kullanılmalıdır |
| kid | İzin verilen anahtar kümesindeki anahtarı gösteriyor mu? | İmza doğrulanamazsa reddedilir | Tek başına güven kanıtı değildir |
Sunucu, imzayı beklediği anahtarla doğruladıktan sonra
iss değerini tam olarak kendi yapılandırmasındaki yayıncıyla, aud değerini API kimliğiyle karşılaştırır. Tanımlı saat toleransı dışında şimdi exp değerinden küçük ve nbf değerinden büyük/eşitse token zaman bakımından kullanılabilir. Ancak bu, kullanıcının her işlemi yapabileceği anlamına gelmez; sipariş okuma isteği için scope veya benzeri uygulamaya özel yetki de ayrıca kontrol edilir. İmza veya bu zorunlu kontrollerden biri başarısızsa sunucu isteği yetkisiz kabul etmelidir.Uygulanabilir doğrulama sırası
- Tokenın beklenen taşıma biçiminde, bozulmamış ve beklenen JWT/JWS bölüm sayısında olduğunu kontrol edin.
- Header içindeki
algdeğerini izin verilen algoritmalarla karşılaştırın; izin verilmeyen veya beklenmeyen algoritmayı reddedin. - Güvenilir yapılandırmadan veya güvenilir anahtar deposundan doğru anahtarı seçin.
kidbulunuyorsa yalnızca izin verilen anahtar kümesinde arayın. - İmzayı doğrulayın. Bu aşama geçmeden payload içindeki claim değerlerini kimlik veya yetki kanıtı olarak kullanmayın.
- Gerekli
iss,aud,expvenbfkontrollerini uygulayın; saat farkı toleransını sınırlı ve açık bir politika olarak belirleyin. - İsteğin bağlamına göre
sub, kapsam, roller ve diğer uygulamaya özel claimleri kontrol edin. Başarılı kimlik doğrulamayı otomatik olarak yetki verilmesiyle karıştırmayın. - Başarısız kontrolde tokenı kullanmadan uygun bir yetkisiz veya geçersiz kimlik doğrulama yanıtı verin; ayrıntılı imza ve anahtar bilgilerini istemciye döndürmeyin.
Sık yapılan hatalar
Tokenı yalnızca decode ederek geçerli saymak,
exp alanını kontrol etmemek ve aud değerini hiç doğrulamamak en yaygın hatalardandır. Doğrulamayı elle yazmak yerine bu kontrolleri açıkça yapılandırabildiğiniz, bakımı yapılan bir JWT kütüphanesi kullanın. Bir başka hata, headerdaki kid değerini doğrudan dosya adı, URL veya sorgu olarak kullanarak anahtar seçmektir; anahtar seçimi güvenilir bir allowlist veya yapılandırmayla sınırlandırılmalıdır. Ayrıca scope, rol veya kullanıcı kimliği imzalı olsa bile istenen işlemin yetkili olduğu ayrıca değerlendirilmelidir.Sık sorulan sorular
JWT içinde olmayan bir alanı zorunlu tutabilir miyim?
Evet.
tenant_id, scope veya uygulamanıza özgü başka bir claim için varlık, tür ve izin verilen değerleri kendi doğrulama politikanızda zorunlu kılabilirsiniz.İmzalı JWT içine parola veya sır koyabilir miyim?
İmza gizlilik sağlamaz; sıradan imzalı JWT’nin payload’u Base64URL çözülerek okunabilir. Parola, API anahtarı veya gereksiz kişisel veri taşımayın. Şifreleme ihtiyacı ayrı bir tasarım ve doğrulama profili gerektirir.exp yoksa token otomatik olarak geçerli midir?
Hayır. Uygulama süre sonunu zorunlu tutuyorsa
exp eksikliği reddetme nedenidir. Süre politikası açıkça belirlenmemiş tokenlar sınırsız ömürlüymüş gibi kabul edilmemelidir.