IETF tarafından yayımlanan RFC 7519, JSON Web Token standardını tanımlar. JWT içindeki claim değerleri bir JSON nesnesi olarak taşınabilir ve token; JSON Web Signature yani JWS kullanılarak imzalanabilir veya JSON Web Encryption yani JWE kullanılarak şifrelenebilir. Bu nedenle her JWT’nin şifreli olduğunu düşünmek önemli bir güvenlik hatasıdır.
JWT kullanımı yaygınlaştıkça yanlış algoritma doğrulaması, zayıf anahtarlar, issuer ve audience kontrollerinin yapılmaması, token türlerinin birbirine karıştırılması ve saldırgan tarafından kontrol edilen anahtar kaynaklarının kullanılması gibi çeşitli saldırılar ortaya çıkmıştır. IETF bu risklere karşı RFC 8725 belgesini yayımlayarak güncel JWT güvenlik uygulamalarını tanımlamıştır.
Bu rehberde JWT güvenliği nedir sorusunu yalnızca teorik olarak değil; üretim ortamında uygulanabilecek 12 kritik güvenlik kontrolü üzerinden ele alacağız.
JWT Güvenliği Nedir? Hızlı Bakış
| Kontrol Alanı | Temel Amaç |
|---|---|
| Algoritma doğrulaması | Token içindeki alg değerine körü körüne güvenilmesini engeller. |
| İmza doğrulaması | Token’ın güvenilir taraf tarafından oluşturulduğunu kontrol eder. |
| Issuer kontrolü | Token’ın beklenen kimlik sağlayıcısından geldiğini doğrular. |
| Audience kontrolü | Token’ın doğru API veya servis için üretildiğini doğrular. |
| Expiration | Süresi dolmuş token’ın kullanılmasını engeller. |
| Anahtar güvenliği | Signing key ele geçirilmesi veya tahmin edilmesi riskini azaltır. |
| Token türü | ID Token ile Access Token gibi farklı tokenların karıştırılmasını engeller. |
| Güvenli depolama | Token’ın XSS, log veya istemci sızıntılarıyla ele geçirilmesini azaltır. |
JWT Güvenliği Nedir ve Neden Önemlidir?
JWT güvenliği nedir sorusunun temelinde token’a güvenmeden önce token’ın kim tarafından üretildiğinin, hangi sistem için üretildiğinin, hangi algoritmayla korunduğunun ve hâlâ geçerli olup olmadığının doğrulanması bulunur.
JWT yapısında genellikle üç bölüm görülür:
- Header
- Payload
- Signature
Bu bölümler nokta karakteriyle ayrılır. Örneğin tipik bir JWS tabanlı JWT şu yapıya benzer:
xxxxx.yyyyy.zzzzz
Header bölümünde kullanılan algoritma gibi metadata bulunabilir. Payload bölümünde kullanıcı kimliği, issuer, audience, expiration ve uygulamaya özel claim değerleri bulunabilir. Signature ise token’ın bütünlüğünü ve imzalayan tarafı doğrulamak için kullanılır.
Buradaki kritik nokta şudur: Base64URL kodlama şifreleme değildir. İmzalanmış fakat şifrelenmemiş bir JWT’nin payload kısmı kullanıcı tarafından okunabilir. Bu nedenle parola, kredi kartı bilgisi veya gereksiz hassas kişisel verileri JWT içine koymak güvenli değildir.
JWT Güvenliği Nedir? Token Güvenliği İçin 12 Kritik Önlem
1. İzin Verilen Algoritmaları Sunucu Tarafında Sabitleyin
JWT güvenliğinde en kritik kontrollerden biri kullanılan kriptografik algoritmanın doğrulanmasıdır. RFC 8725, uygulamaların kabul edeceği algoritma listesini açık biçimde belirlemesi gerektiğini söyler.
Uygulama, token header bölümünde gelen alg değerini okuyup otomatik olarak o algoritmayı kullanmamalıdır. Bunun yerine hangi algoritmaların kabul edildiği sunucu yapılandırmasında önceden belirlenmelidir.
Örneğin sisteminiz yalnızca RS256 kullanıyorsa doğrulama katmanı başka algoritmaları otomatik olarak kabul etmemelidir.
JWT güvenliği nedir yaklaşımında temel kural, saldırganın token içerisindeki metadata ile güvenlik politikasını belirlemesine izin vermemektir.
2. JWT İmzasını Her İstekte Doğrulayın
JWT içeriğini decode etmek ile token’ı doğrulamak aynı işlem değildir. Bir token’ın payload bölümünü okuyabilmek onun güvenilir olduğunu göstermez.
API, JWT içerisindeki claim değerlerini kullanmadan önce kriptografik imzayı doğrulamalıdır. İmza geçersizse token içerisindeki kullanıcı kimliği, rol veya diğer claim değerleri hiçbir şekilde kullanılmamalıdır.
İmza doğrulaması atlanırsa saldırgan kendi oluşturduğu token içerisine:
- yönetici rolü,
- başka kullanıcı kimliği,
- geniş yetki,
- sahte issuer
gibi değerler ekleyebilir.
3. “none” veya Beklenmeyen Algoritmaları Kabul Etmeyin
JWT ekosisteminin geçmişteki en bilinen güvenlik problemlerinden biri algoritma doğrulamasının yanlış yapılmasıydı. Bazı hatalı uygulamalar imzasız tokenların veya uygulamanın beklemediği algoritmaların kabul edilmesine yol açabiliyordu.
Modern JWT kütüphaneleri bu konuda daha güvenli olsa da uygulama katmanında whitelist yaklaşımı kullanılmalıdır.
Örneğin:
allowedAlgorithms = ["RS256"]
gibi açık bir güvenlik politikası, token’ın kendi algoritmasını seçmesine göre daha güvenlidir.
4. Issuer Claim Değerini Mutlaka Doğrulayın
iss yani issuer claim’i token’ı hangi sistemin oluşturduğunu belirtir.
Bir API yalnızca kurumunuzun authorization server’ı tarafından üretilen tokenları kabul edecekse issuer değeri tam olarak beklenen değerle eşleşmelidir.
Örneğin API:
https://identity.example.com
issuer değerini bekliyorsa saldırgan tarafından kontrol edilen başka bir authorization server’dan alınan JWT kabul edilmemelidir.
RFC 8725 issuer doğrulamasını JWT güvenliğinin temel kontrolleri arasında değerlendirir.
5. Audience Claim Değerini Kontrol Edin
aud yani audience değeri token’ın hangi servis veya API için oluşturulduğunu belirtir.
Örneğin:
aud = payment-api
olarak oluşturulan token’ın farklı bir yönetim API’sinde kullanılmasına izin verilmemelidir.
Audience kontrolü yapılmadığında bir sistem için alınmış geçerli JWT başka bir servise karşı yeniden kullanılabilir.
Bu nedenle JWT güvenliği nedir denildiğinde issuer ve audience kontrolleri birlikte düşünülmelidir.
6. Expiration ve Zaman Claim’lerini Kontrol Edin
JWT standardındaki önemli claim değerlerinden biri exp yani expiration time değeridir.
API, token’ın süresinin geçip geçmediğini her istekte kontrol etmelidir. Uzun süre geçerli access token kullanmak token ele geçirilmesi durumunda saldırganın kullanım süresini artırabilir.
Ayrıca kullanılan sisteme göre:
exp— expiration time,nbf— not before,iat— issued at
gibi zaman claim değerleri değerlendirilebilir.
Sunucular arasındaki küçük saat farkları için sınırlı clock skew toleransı kullanılabilir; ancak aşırı geniş tolerans token süresini gereksiz şekilde uzatabilir.
7. Signing Key ve Secret Değerlerini Güçlü Tutun
Simetrik algoritmalar kullanıldığında güvenlik büyük ölçüde paylaşılan secret değerinin gücüne bağlıdır. Tahmin edilebilir veya kısa secret kullanımı brute-force saldırılarını kolaylaştırabilir.
RFC 8725 kriptografik anahtarların yeterli entropy yani rastgelelik taşıması gerektiğini vurgular.
Üretim sistemlerinde anahtarları kaynak kod içine yazmak yerine:
- Secrets Manager,
- Key Management Service,
- HSM,
- Vault
gibi güvenli sistemlerde yönetmek daha doğru yaklaşımdır.
Anahtar rotasyonu için de önceden plan yapılmalıdır.
8. ID Token ile Access Token’ı Birbirine Karıştırmayın
Modern kimlik sistemlerinde aynı kullanıcı oturumu sırasında farklı JWT türleri üretilebilir.
Örneğin OpenID Connect sistemlerinde ID Token kullanıcının kimliğine ilişkin bilgiler taşırken Access Token API’ye erişim amacıyla kullanılabilir.
ID Token’ın doğrudan API access token’ı gibi kabul edilmesi ciddi yetkilendirme sorunları oluşturabilir.
RFC 8725 farklı JWT türleri için birbirinden bağımsız doğrulama kuralları kullanılmasını önerir. Bu yaklaşım cross-JWT confusion saldırılarının azaltılmasına yardımcı olur.
9. JWT Türünü Açıkça Belirtin ve Doğrulayın
Bir sistem içerisinde birden fazla JWT türü kullanılıyorsa tokenların amacı açık biçimde ayrılmalıdır.
RFC 8725 explicit typing yani açık token türü kullanımını önerir. Uygun senaryolarda typ header değeri kullanılarak token türleri birbirinden ayrılabilir.
Örneğin bir password reset token ile API access token aynı doğrulama mantığından geçirilmemelidir.
JWT güvenliği nedir yaklaşımında her token türü için:
- farklı audience,
- farklı doğrulama kuralları,
- farklı kullanım amacı,
- mümkünse ayrı anahtar veya güven sınırı
tanımlamak token karıştırma saldırılarını azaltabilir.
10. jku ve x5u Gibi Uzak Anahtar Kaynaklarını Kontrol Edin
Bazı JWT/JWS yapılarında token header bölümü doğrulama anahtarının bulunduğu URL gibi bilgileri taşıyabilir.
Sunucu saldırgan tarafından sağlanan herhangi bir URL’ye bağlantı kurarsa SSRF veya saldırgan tarafından kontrol edilen anahtarların kullanılmasına ilişkin güvenlik problemleri oluşabilir.
Bu nedenle anahtar kaynakları yalnızca önceden güvenilen adreslerden alınmalı ve URL doğrulaması sıkı biçimde yapılmalıdır.
Authorization Server’ın JWKS endpoint’i biliniyorsa istemci veya API yalnızca bu güvenilir kaynağı kullanmalıdır.
11. JWT İçine Hassas Verileri Gereksiz Yere Koymayın
Yaygın yanlış inanışlardan biri JWT içerisindeki payload bölümünün gizli olduğudur.
JWS tabanlı normal JWT yapısındaki payload şifrelenmez. Base64URL ile kodlandığı için herhangi bir kullanıcı token’ı decode ederek payload içeriğini okuyabilir.
Bu nedenle JWT içine mümkün olduğunca yalnızca uygulamanın gerçekten ihtiyaç duyduğu claim değerlerini koyun.
Şunları token içinde gereksiz yere taşımaktan kaçının:
- parolalar,
- API secret değerleri,
- kredi kartı bilgileri,
- özel anahtarlar,
- gereksiz hassas kişisel bilgiler.
Gerçek gizlilik gerekiyorsa uygun JWE veya farklı güvenli veri taşıma mekanizmaları değerlendirilmelidir.
12. JWT Tokenlarını Güvenli Saklayın ve İzleyin
JWT ne kadar güçlü imzalanmış olursa olsun token saldırganın eline geçerse token geçerlilik süresi boyunca kötüye kullanılabilir.
Web uygulamalarında token depolama stratejisi uygulamanın tehdit modeline göre belirlenmelidir. Özellikle XSS saldırısı bulunan bir uygulamada JavaScript tarafından erişilebilen depolama alanları risk oluşturabilir.
Tokenların uygulama loglarında, hata mesajlarında, analytics sistemlerinde veya URL parametrelerinde görünmesini engelleyin.
JWT güvenliği nedir yaklaşımının son adımı çalışma zamanı izlemesidir. Beklenmeyen IP adresleri, olağan dışı token kullanımı, hatalı signature denemeleri ve issuer/audience doğrulama hataları merkezi log sistemlerinde izlenebilir.
JWT Güvenliği Nedir? En Kritik Claim Kontrolleri
| Claim | Anlamı | Güvenlik Kontrolü |
|---|---|---|
| iss | Issuer | Beklenen token üreticisiyle tam eşleşmeli. |
| aud | Audience | Token’ın mevcut API için üretildiği doğrulanmalı. |
| exp | Expiration Time | Süresi geçen token reddedilmeli. |
| nbf | Not Before | Token belirlenen zamandan önce kullanılmamalı. |
| iat | Issued At | Token’ın oluşturulma zamanı bağlama göre kontrol edilmeli. |
| sub | Subject | Token’ın temsil ettiği kullanıcı veya varlık doğru yorumlanmalı. |
| jti | JWT ID | Gereken sistemlerde tokenı benzersiz tanımlamak ve tekrar kullanımını izlemek için kullanılabilir. |
JWT İmzalıysa İçeriği Gizli midir?
Hayır. Bu, JWT güvenliği nedir konusunda yapılan en yaygın hatalardan biridir.
Bir JWT’nin dijital olarak imzalanması payload verisinin gizlendiği anlamına gelmez. İmzanın temel amacı bütünlük ve kaynağı doğrulamaktır.
Bir saldırgan JWT’yi okuyabilir fakat güvenli imza doğrulaması uygulanıyorsa içeriği değiştirip geçerli token olarak kullanamaz.
Verinin gizli olması gerekiyorsa JWE gibi şifreleme sağlayan yapıların kullanılması gerekir. JWT standardı tokenların JWS veya JWE yapıları içerisinde kullanılabileceğini tanımlar.
JWT ile OAuth 2.0 Aynı Şey mi?
Hayır. JWT bir token formatıdır. OAuth 2.0 ise bir yetkilendirme çerçevesidir.
OAuth 2.0 sistemleri JWT biçiminde access token kullanabilir ancak bunu yapmak zorunda değildir. Benzer şekilde JWT, OAuth dışında farklı uygulama ve protokollerde de kullanılabilir.
Bu nedenle OAuth güvenliği ve JWT güvenliği nedir konuları birbirini tamamlayabilir ancak aynı kavram değildir.
JWT Güvenliğinde Asimetrik ve Simetrik İmzalama Farkı
| Yaklaşım | Özellik |
|---|---|
| HMAC / Simetrik | İmzalama ve doğrulama için paylaşılan secret kullanılır. |
| RSA / Asimetrik | Private key ile imzalanır, public key ile doğrulanabilir. |
| ECDSA / Asimetrik | Eliptik eğri tabanlı public/private key yaklaşımı kullanır. |
Mikroservis veya çok sayıda resource server bulunan yapılarda asimetrik imzalama, doğrulama yapan servislere private key dağıtılması gerekmemesi nedeniyle önemli avantaj sağlayabilir.
Ancak algoritma seçimi uygulamanın mimarisi ve güvenlik gereksinimlerine göre yapılmalı, güncel ve güvenilir JWT/JOSE kütüphaneleri kullanılmalıdır.
JWT Güvenliği Nedir? Uygulama Kontrol Listesi
- Kabul edilen JWT algoritmalarını whitelist yöntemiyle belirleyin.
- Her token isteğinde signature doğrulaması yapın.
- Beklenmeyen veya imzasız algoritmaları reddedin.
- Issuer yani iss değerini doğrulayın.
- Audience yani aud değerini doğrulayın.
- Expiration yani exp kontrolü uygulayın.
- Signing key ve secret değerlerini güvenli yönetin.
- ID Token ile Access Token’ı birbirinden ayırın.
- Farklı JWT türleri için ayrı doğrulama kuralları kullanın.
- jku, x5u ve diğer uzak anahtar kaynaklarını sınırlandırın.
- Payload içine gereksiz hassas veri eklemeyin.
- Token sızıntısı ve anormal doğrulama olaylarını izleyin.
JWT Güvenliği Nedir? Sık Yapılan 10 Hata
- JWT’yi yalnızca decode edip signature doğrulamamak
- Token’ın belirttiği algoritmaya otomatik güvenmek
- Issuer kontrolü yapmamak
- Audience kontrolünü atlamak
- Çok uzun token geçerlilik süresi kullanmak
- Zayıf HMAC secret kullanmak
- ID Token’ı Access Token gibi kullanmak
- JWT payload içeriğini şifreli sanmak
- Token değerlerini uygulama loglarına yazmak
- Signing key rotasyonu planlamamak
JWT Güvenliği Nedir? Sık Sorulan Sorular
JWT güvenliği nedir?
JWT güvenliği nedir sorusuna; JWT tokenlarının algoritma, imza, issuer, audience, süre, anahtar, token türü ve depolama açısından doğru şekilde doğrulanması ve korunması şeklinde cevap verilebilir.
JWT şifreli midir?
Her JWT şifreli değildir. JWS tabanlı JWT imzalanabilir fakat payload bölümü okunabilir. Gizlilik gerekiyorsa JWE gibi şifreleme sağlayan yapı kullanılmalıdır.
JWT decode etmek güvenli doğrulama mıdır?
Hayır. Decode işlemi yalnızca token içerisindeki veriyi okumaya yarar. Güvenilir kullanım için signature ve gerekli claim değerleri doğrulanmalıdır.
JWT’de audience kontrolü gerekli mi?
Evet. Audience kontrolü token’ın mevcut API veya servis için oluşturulduğunu doğrulamaya yardımcı olur.
JWT içine parola konulur mu?
Hayır. JWT payload içine parola, private key veya gereksiz hassas bilgiler eklenmemelidir.
JWT ile OAuth 2.0 aynı şey midir?
Hayır. JWT bir token formatı, OAuth 2.0 ise yetkilendirme çerçevesidir. OAuth sistemleri JWT kullanabilir ancak bu zorunlu değildir.
JWT token süresi ne kadar olmalı?
Tek bir evrensel süre yoktur. Token yaşam süresi uygulamanın risk seviyesine ve kullanım modeline göre mümkün olduğunca sınırlı belirlenmeli; uzun süreli erişim gerekiyorsa güvenli yenileme mekanizmaları kullanılmalıdır.
İlgili İçerikler
OAuth 2.0 Güvenliği Nedir? 10 Kritik Önlem
Workload Identity Federation Nedir?
Resmî ve Güvenilir Kaynaklar
IETF / RFC Editor — RFC 8725: JSON Web Token Best Current Practices
IETF / RFC Editor — RFC 7519: JSON Web Token
Sonuç: JWT Güvenliği Nedir?
JWT güvenliği nedir sorusuna yalnızca “token’ı imzalamak” şeklinde cevap vermek yeterli değildir. Güvenli JWT kullanımı; kabul edilen algoritmaların sınırlandırılması, signature doğrulaması, issuer ve audience kontrolleri, expiration yönetimi, güçlü signing key kullanımı ve token türlerinin birbirinden ayrılması gibi birden fazla güvenlik katmanını gerektirir.
JWT payload bölümünün şifreli olmadığını bilmek, hassas bilgileri token dışında tutmak ve ID Token ile Access Token gibi farklı JWT türlerini ayrı politikalarla doğrulamak da kritik öneme sahiptir.
RFC 7519 standardı ile RFC 8725 Best Current Practices belgesi birlikte değerlendirildiğinde JWT güvenliği nedir yaklaşımının temel amacı açıkça görülür: Token içerisindeki veriye yalnızca token yapısına bakarak güvenmemek, her güvenlik varsayımını kriptografik ve uygulama seviyesinde doğrulamaktır.
