JWT mi Session mi? Authentication Seçimi ve Güvenlik
Giriş: Kimlik Doğrulama Seçimi Neden Önemlidir?
JWT (JSON Web Token) ve session-based authentication, modern web uygulamalarının temel taşlarıdır. İkisi de kullanıcı kimlik doğrulamasını sağlarken, mimarisi, güvenlik profili ve ölçeklenebilirliği açısından önemli farklılıklar taşırlar. Bir teknoloji yığını kurarken, bu iki yaklaşımdan birini seçmek, uygulamanın güvenliği, performansı ve bakım kolaylığını doğrudan etkiler. Doğru seçim, sadece şu anki ihtiyaçlara değil, gelecekteki büyüme senaryolarına da bağlıdır.
Session-Based Authentication: Sunucu Merkezli Yaklaşım
Session-based kimlik doğrulama, geleneksel ve hâlen yaygın olarak kullanılan bir yöntemdir. Kullanıcı başarıyla oturum açtığında, sunucu bellekte veya veritabanında bir session nesnesi oluşturur ve istemciye bir session ID gönderir. Tarayıcı bu ID'yi genellikle cookie'de saklar ve sonraki her istekte sunucuya geri gönderir.
Session'un avantajları:
- Sunucu tarafında tam kontrol: Oturum bilgileri sunucuda tutulduğu için, oturum iptal etmek anlık olur
- Kullanıcı aktivitesi takibi: Her isteğin kaydı sunucuda bulunur, denetim kolaylaşır
- Refresh mekanizması: Session timeout ile otomatik oturum kapatma yapılabilir
- CSRF koruması: Cookie tabanlı session'lar, CSRF token mekanizması ile korunabilir
Dezavantajları ve riskleri:
- Sunucu yükü: Her aktif kullanıcı için bellekte alan gerekir; milyonlarca eş zamanlı oturum maliyetli hale gelir
- Yatay ölçeklendirme zorluğu: Birden fazla sunucu kullanıyorsanız, session senkronizasyonu veya sticky sessions gerekir
- Session fixation saldırıları: Atanan session ID'nin manipüle edilmesi riski vardır
- CORS uyumsuzluğu: Çoklu domain senaryolarında cookie tabanlı session'lar kısıtlı olur
JWT: Stateless ve Taşınabilir Kimlik Doğrulama
JSON Web Token, verinin base64 ile kodlandığı, imzalanmış ve isteğe bağlı olarak şifrelenen bir standarttır. Kullanıcı oturum açtığında, sunucu bir token üretir; bu token, herhangi bir durum bilgisi tutmadan istemci tarafında saklanır ve her API isteğinde gönderilir. Token, kendi başına yeterli bilgi taşır—veritabanı sorgusu gerek kalmaz.
JWT'nin avantajları:
- Stateless mimarı: Sunucu session saklama ihtiyacı duymazsa, bellek tasarrufu sağlanır
- Ölçeklenebilirlik: Birden fazla sunucu arasında senkronizasyon gereksizdir
- Mobil ve API uygunluğu: Token, URL parametresi, header veya localStorage'da taşınabilir
- Microservices mimarisi: Servislerin birbirinden bağımsız olarak token doğrulaması yapabilir
- CORS dostu: Cross-origin isteklerinde cookie kısıtlaması olmaz
Güvenlik riskleri ve zorlukları:
- Token iptalinin zorlığu: Token'ın süresi doluncaya kadar geçerliliğini sunucu anında durduranamaz
- XSS (Cross-Site Scripting) tehdidi: localStorage'da tutulan token, JavaScript ile çalınabilir
- Token boyutu: İçerdikleri bilgi miktarı arttıkça, her istekte gönderilen veri büyür
- Secret key yönetimi: İmzalamada kullanılan anahtarın sızması, tüm token'ları geçersiz hale getirir
Refresh Token Stratejileri ve Hibrit Yaklaşım
Modern uygulamalar, saf JWT veya saf session yerine, ikisinin avantajlarını birleştiren hibrit modeller tercih eder. Bu yaklaşımda, kısa süreli bir access token ve uzun süreli bir refresh token kullanılır.
Tipik akış:
- Kullanıcı oturum açar; sunucu 15 dakikalık bir access token ve 7 günlük bir refresh token verir
- API isteklerinde access token kullanılır; token bittiğinde refresh token ile yeni bir access token alınır
- Refresh token, eğer istenmiyorsa, httpOnly cookie'de saklanarak XSS'den korunur
Bu strateji, JWT'nin ölçeklenebilirliği ile session'un kontrol kolaylığını birleştirir. Refresh token bir veritabanında kaydedilirse, istenmeyen oturum açılış anında iptal edilebilir.
Karşılaştırma Tablosu: Hangi Durumlarda Hangisi?
| Kriter | Session | JWT |
|---|---|---|
| Sunucu Yükü | Yüksek (bellekte session nesneleri) | Düşük (stateless) |
| Ölçeklenebilirlik | Sınırlı (senkronizasyon gerekli) | İyi (bağımsız sunucular) |
| Oturum İptali | Anlık ve güvenilir | Zor (token süresi dolar kadar beklemek gerekir) |
| Mobil Uygunluk | Orta (cookie sorunları) | İyi (token taşınabilir) |
| Güvenlik Karmaşıklığı | CSRF koruması basit | XSS ve token çalınma riski |
| İdeal Senaryo | Monolitik, tek sunuculu uygulamalar | Microservices, API-first mimarisi |
Best Practices ve Güvenlik Önerileri
Session kullanıyorsanız:
- Sunucu tarafında session depolama için Redis veya Memcached kullanın
- Session timeout'ını makul bir süreye ayarlayın (orta değer: 30 dakika)
- HttpOnly ve Secure flag'lerini cookie'lere uygulayın
- CSRF token'ı her durumda imzalı form istekleriyle kullanın
JWT kullanıyorsanız:
- Access token'ın süresi kısa (10-15 dakika) olmalı; refresh token'ı ise httpOnly cookie'de saklayın
- Token payload'ında hassas veriler (parola, tam SSN) koymayın
- Signing secret'i güçlü ve düzenli olarak rotasyona sokulacak şekilde yönetin
- Token revocation için bir siyah liste veya veritabanı sorgusu önünde durmayın
Her iki yaklaşım için:
- HTTPS kullanın; şifrelenmemiş kanalda kimlik doğrulama bilgisi asla gitmemeli
- Oturum ve token verilerini loglayarken, hassas bilgileri maskeleme yapın
- Kısıtlı oturum denemesi (brute-force) koruması ekleyin
Karar Kriterleri
Session mi JWT mi seçimi, teknolojik mimarinin yanında, ekip deneyimi ve mevcut altyapıya da bağlıdır. Monolitik, klasik web uygulaması geliştiriyorsanız ve kullanıcı sayısı orta seviyeliyse, session temelleri uygulanabilir. Microservices, mobile-first veya çok yüksek eşzamanlılık senaryosundaysanız, JWT veya hibrit yaklaşım (short-lived access token + refresh token) daha uygun olacaktır. Nihai olarak, her iki yöntemi de doğru bir şekilde uygulamak mümkündür; tercih ettiğiniz yaklaşıma güvenlik best practices'leri dikkatlice uygulayın.