Kimlik doğrulama tartışması, yıllardır aynı iki rakip etrafında dönüyor: JWT ve sunucu tarafı oturum. 2026 itibarıyla da ikisi de ölümedi; çünkü ikisi de farklı bir sorunun cevabı. Doğru tercih, hangisinin "daha modern" olduğuna değil, uygulamanızın ne sorduğuna bağlıdır.

Tartışmanın kalbindeki soru şudur: sunucu, kullanıcının kim olduğunu nereden bilecek? Cevap istemcideyse belirteç, sunucudaysa oturum doğar. Gerisi — çerez mi başlık mı, kısa ömür mü uzun ömür mü — bu ilk karara verilen ayrıntıdır.

JWT: Durumsuz ve Taşınabilir

JWT, kimlik bilgilerini kendi içinde taşıyan imzalı bir belirteçtir. Sunucu doğrulamak için veritabanına bakmaz; imzayı kontrol eder ve devam eder. Bu durumsuzluk, yatay ölçeklemede ve servisler arasında kimlik taşımada hâlâ güçlü bir argümandır.

Aynı özellik, mobil uygulamalar ve üçüncü taraf entegrasyonları için de geçerlidir: belirteç, üreten sunucu ile doğrulayan sunucunun aynı olması zorunluluğunu ortadan kaldırır. Mikroservis mimarisinde her servisin oturum mağazanıza ayrı ayrı bağlanması yerine, imzayı doğrulaması çoğu zaman daha temiz bir çözümdür.

const token = jwt.sign(
  { sub: kullanici.id, rol: kullanici.rol, exp: Math.floor(Date.now() / 1000) + 900 },
  process.env.JWT_GIZLI_ANAHTARI,
);

Ama durumsuzluk bir bedel öder: belirteç, süresi dolana kadar geçerlidir. Kullanıcı şifresini değiştirse, oturumu kapatılsa bile yayılan token geçersiz sayılmaz — sunucu tarafında iptal listesi tutmadıkça. Bu da JWT'nin gizli madde haline gelen iptal sorunudur ve her kısa ömürlü token tasarımının kalbinde yatar.

Oturum: Kontrol Sunucuda

Sunucu tarafı oturumda kimlik bilgisi sunucuda saklanır, istemciye yalnızca bir çerez kimliği verilir. İptal anlıktır: oturumu sildiniz, erişim bitti. Şifre değişikliği, hesap kilidi ve "tüm cihazlardan çıkış" gibi senaryolar doğal olarak çalışır. Redis gibi hızlı bir mağazada oturum tutmak, gecikme maliyetini önemsiz hâle getirir.

const oturum = await redis.get(`oturum:${cerezId}`);
if (!oturum) return redirect('/giris');

Bu yaklaşımın maliyeti, her isteğin sunucu tarafı bir aramaya tabi olması ve oturumun bir mağazaya bağlı olmasıdır. Küçük bir uygulamada bu önemsizdir; ama çoklu bölge dağıtımında tutarlılık maliyeti belirginleşir. Zaten bir Redis'iniz varsa bu arama milisaniyenin altındadır; ölçek büyüyene kadar görünmez kalır.

2026'da Pratik Cevap

Bugünün ortak deseni ikisini birleştirmektir: kısa ömürlü erişim belirteci, uzun ömürlü sunucu tarafı yenileme belirteci. Erişim belirteci beş-on dakika yaşar; iptal edilemez ama kısa ömrü riski sınırlandırır. Yenileme belirteci ise sunucuda tutulur ve iptal edilebilir.

Bu hibrit desenin bakım bedelini de göze alın: iki belirteç, bir yenileme akışı ve belirtecin tazelenmesi demektir. Basit bir kurumsal uygulama için bu makineyi kurmak, gerekçesinden büyük olabilir.

Küçük ve orta ölçekli uygulamalar için sunucu tarafı oturum, 2026'da da en az sürprizli yoldur. JWT'ye gerçekten ihtiyaç duyduğunuz an, servisler arası kimlik taşıma gerektiğidir; yani mimariniz dağıtıkken. Tersini seçmek de mümkün: mimariniz durumsuzken oturumu zorlamak, dağıtıkken durumsuzluk taklidi yapmak kadar yanlıştır.

Karar verirken bir soruyu da kendinize sorun: "tüm cihazlardan çıkış" özelliğini bu ay gerçekten yazacak mısınız? Cevap evetse oturum, tasarımı zorlamayan ve iptalin anlık olduğu yoldur. Cevap "şimdilik hayır"sa ve kimlik doğrulamayı zaten bir sağlayıcıya devretmeyi planlıyorsanız, kısa ömürlü JWT bu zorunluluğu erteleyen makul bir tercih olabilir.