API Güvenliği: JWT ve OAuth 2.0 Hataları

JWT güvenli midir?

JWT bir format olarak güvenlidir; güvensiz olan, yaygın uygulama hatalarıdır. Tarihteki büyük JWT olaylarının neredeyse tamamı — imzasız token kabulü, algoritma karmaşası, doğrulanmayan claim'ler — standardın değil, implementasyonun hatasıydı. Bu yazı, JWT ve OAuth 2.0 kullanan API'lerde tekrar tekrar görülen hataları ve doğrularını derler.

Klasik JWT hataları ve karşı önlemler

Hata	Sonucu	Doğrusu
alg: none kabulü	İmzasız token ile kimlik sahteciliği	Algoritma izin listesi; none asla kabul edilmez
HS256/RS256 karmaşası	Açık anahtarın HMAC sırrı gibi kullanılması	Beklenen algoritmayı sabitle, anahtar türünü doğrula
exp/iat kontrolsüzlüğü	Süresiz geçerli token'lar	Süre claim'lerini zorunlu doğrula; kısa TTL
aud/iss doğrulamaması	Bir servisin token'ının başka serviste geçmesi	Audience ve issuer'ı her serviste doğrula
Token'da hassas veri	Payload şifreli değildir, yalnızca imzalıdır	Kişisel/hassas veriyi token'a koyma
İptal mekanizması yokluğu	Ele geçirilen token süre sonuna dek geçerli	Kısa TTL + rotasyonlu refresh + gerekirse kara liste

İmza doğrulama: tek doğru sıra

Sunucu tarafında her istekte sıra değişmez: önce imza, beklenen algoritmayla ve doğru anahtarla doğrulanır; sonra exp, nbf, iss ve aud claim'leri kontrol edilir; ancak bunlardan sonra token'ın içeriğine güvenilir. Anahtarlar JWKS uç noktasından, kid başlığına göre ve önbellekli çekilmeli; anahtar rotasyonu, eski ve yeni anahtarın bir süre birlikte yayımlanmasıyla kesintisiz yapılmalıdır.

Token ömrü ve yenileme: kısa yaşa, sık yenile

Erişim token'ları dakikalar mertebesinde kısa ömürlü olmalı; uzun oturumlar yenileme token'ıyla taşınmalıdır. Yenileme token'ında güncel iyi pratik rotasyondur: her kullanımda yeni refresh üretilir, eskisi geçersizleşir; aynı eski token ikinci kez görülürse tüm oturum zinciri iptal edilir — bu, çalınan refresh token'ın tespit mekanizmasıdır. OAuth 2.0 tarafında ise tarayıcı ve mobil istemciler için standart akış, PKCE'li authorization code akışıdır; implicit akış artık önerilmez.

Scope ve yetki: token her kapıyı açmamalı

Scope'lar dar tanımlanmalı — okuma ile yazma ayrılmalı, yönetim uçları ayrı scope istemeli — ve sunucu, scope'u her uç noktada gerçekten kontrol etmelidir. Mikroservis mimarilerinde ek kural: bir servis için üretilen token'ın başka serviste geçmemesi için audience doğrulaması servis bazında yapılmalıdır.

Hız limiti ve kaba kuvvet: kimlik uçlarının sigortası

Token üreten uç noktalar (login, refresh, client credentials) hız limiti ve anomali izlemesi olmadan yayımlanmamalıdır; kimlik bilgisi doldurma (credential stuffing) saldırılarının ilk hedefi bu uçlardır. Başarısız denemelerin loglanması ve alarma bağlanması, A09 (loglama eksikliği) ile bu başlığın kesişimidir.

İş etkisi: API'niz artık ürününüzdür

B2B entegrasyonlarda API güvenliği doğrudan satış konusudur: kurumsal müşterinin entegrasyon ekibi OAuth akışlarınızı, token ömürlerinizi ve iptal stratejinizi sorar. Belgelenmiş, standartlara uygun bir kimlik mimarisi entegrasyon süresini kısaltır; savunulamayan bir tasarım ise güvenlik değerlendirmesinde projeyi bekletir. Kimlik katmanına yapılan yatırım, entegrasyon satışının altyapısıdır.

Sık sorulan sorular

JWT yerine opak token kullanmalı mıyım?

İç ağda tek yetkilendirme sunucusuyla çalışıyorsanız opak token + introspection sade ve güçlüdür; dağıtık doğrulama gerekiyorsa (çok servis, düşük gecikme) imzalı JWT pratiktir. İkisi meşru mimarilerdir; hangisiyse, doğrulama disiplinini uygulayın.

Token'ı nerede saklamalıyım?

Tarayıcıda httpOnly + Secure + SameSite çerez, XSS'e karşı localStorage'dan daha dayanıklıdır; mobilde Keystore/Keychain kullanılmalıdır.

Refresh token ne kadar yaşamalı?

Uygulamanın risk profiline göre günler-haftalar arası; rotasyon ve yeniden kullanım tespitiyle birlikte. Hareketsiz oturumlar için mutlak bir üst ömür tanımlayın.

API anahtarı ile OAuth aynı şey mi?

Hayır: API anahtarı istemciyi tanımlar, kullanıcıyı ve yetki kapsamını taşımaz. Kullanıcı bağlamı gereken her senaryoda OAuth/OIDC tabanlı token'lar kullanılmalıdır.

API kimlik güvenliği kontrol listesi

Algoritma izin listesi; alg: none reddi test edildi
exp, iss, aud doğrulaması her serviste zorunlu
Erişim token TTL dakikalar mertebesinde; refresh rotasyonlu
JWKS ile anahtar rotasyon planı tanımlı
Scope'lar dar; uç nokta bazında kontrol ediliyor
Kimlik uçlarında hız limiti ve anomali alarmı aktif
Token'larda hassas veri taşınmadığı doğrulandı

SSH Yazılım, API kimlik mimarisi tasarımı, JWT/OAuth denetimi ve entegrasyon güvenliği danışmanlığı sunar. Kimlik katmanınızı birlikte gözden geçirelim.