JWT vs session tartışması çoğu ekipte moda bir token tercihine iner. Asıl ayrım tarayıcıda çalışan uygulama ile API tüketen istemcinin ihtiyaçlarıdır. Bu rehber kimlik modelini istemci türüne göre seçmek için somut bir çerçeve sunar.
Web ekibinde kimlik konusu açıldığında soru çoğu zaman aynıdır: oturum mu JWT mı? jwt vs session karşılaştırması, bir tarafı eski diğerini modern gösteren bir moda seçimine dönüşür. Oysa tarayıcıda çalışan bir uygulama ile API tüketen bir istemci aynı kimlik modelini hak etmez. Kararı kütüphane popülerliği değil, istemcinin nerede çalıştığı, oturumu kimin iptal edeceği ve durumun nerede duracağı belirler.
Bu rehber token formatını övmek için yazılmadı. Amaç, tarayıcı uygulamasını API tüketicisinden ayırarak kimlik modelini iş dilinde seçmenizdir. Hangisinin “daha yeni” olduğu değil, hangisinin sizin istemcinize uyduğu önemlidir.
JWT vs session kararını moda değil istemci belirler
Oturum, sunucunun “bu istek şu kullanıcıya ait” bilgisini kendi tuttuğu modeldir. JWT ise imzalı bir belgenin istemciyle taşındığı, sunucunun her istekte imzayı doğruladığı bir belgedir. Biri durum deposu ister; diğeri taşıyıcıya güvenir. İkisi de kimlik kanıtı üretir. İkisi de yanlış yerde kırılgan olur.
Moda seçim şöyle görünür: “SPA yazıyoruz, o halde JWT.” veya “Klasik site, o halde oturum.” Bu cümleler bazen tesadüfen doğru çıkar. Tesadüf mimari değildir. Asıl soru şudur: kimlik kanıtını tarayıcı mı otomatik gönderecek, yoksa bir API istemcisi mi bilinçli taşıyacak?
Tarayıcı çerezi otomatik ekler. Mobil uygulama, sunucudan sunucuya çağrı ve üçüncü taraf entegrasyon ise kanıtı başlıkta taşır. Bu fark, jwt vs session tartışmasının teknik çekirdeğidir. Token’ı sevmek veya oturumu “eski” ilan etmek bu çekirdeği değiştirmez.
Kimlik modeli kütüphane seçimi değildir. Önce istemciyi, sonra iptal ihtiyacını, en sonda taşıyıcıyı kararlaştırın.
Tarayıcı uygulaması ile API tüketicisini ayırın
Aynı üründe bile iki istemci sınıfı yan yana durabilir. Yönetim paneli tarayıcıda açılır. Mobil uygulama aynı sipariş API’sini çağırır. Muhasebe yazılımı stok bakiyesini çeker. Bu üçü “kullanıcı girişi var” diye tek modele zorlanırsa ya tarayıcı şişer ya API hantallaşır.
Tarayıcı uygulamasında kullanıcı bir origin içinde gezinir. Form gönderir, sayfa yeniler, aynı sitede kalır. Kimlik kanıtının çerezle gitmesi doğaldır. Sunucu oturumu tanır, sayfayı üretir veya aynı sitedeki API’ye cevap verir. Burada asıl iş, oturumun kapanması, şifre değişince eski kanıtın düşmesi ve tarayıcı betiğinin oturum kimliğine ulaşmamasıdır.
API tüketicisi farklıdır. İstemci sizin sayfanız olmayabilir. Çerez beklenmez, aynı site varsayılmaz, çağrı bir sunucudan gelebilir. Kanıtın taşınması bilinçlidir. Süre kısa tutulur. İptal için ek bir kayıt gerekir. KepezWeb tarafında bu ayrım, “tek login ekranı”ndan önce çizilir; çünkü login ekranı ortak olsa bile oturumun ömrü istemciye göre değişir.
Üç istemci, üç beklenti
- Aynı sitede çalışan tarayıcı: çerez ve sunucu oturumu çoğu zaman yeter.
- Sizin API’nizi tüketen mobil veya masaüstü istemci: kısa ömürlü erişim belgesi ve yenileme planı gerekir.
- Başka bir sistemin sunucusu: kullanıcı oturumu değil, servis kimliği ve dar yetki alanı gerekir.
Bu üçünü tek JWT yığınıyla çözmek “stateless olduk” hissi verir. Hissin bedeli, çıkış, çalıntı cihaz ve yetki düşürme gibi günlük işlerin belirsizleşmesidir. Oturumu her yere yaymak da ters yönde hata üretir: çerez beklemeyen istemci takılır, ölçek konuşması erken başlar, asıl ihtiyaç olan iptal netliği kaybolur.
Oturum modeli tarayıcıda ne zaman yeter
Klasik site, yönetim paneli ve aynı origin’de kalan bir arayüz için oturum hâlâ sade ve anlaşılırdır. Kullanıcı girer. Sunucu bir oturum kaydı açar. Tarayıcıya oturum kimliği gider. Sonraki isteklerde sunucu kayda bakar. Çıkış, şifre sıfırlama veya hesap kilidi bu kaydı silmek veya geçersiz kılmakla biter.
Bu model özellikle özel PHP/MySQL yazılım gibi sunucunun sayfayı ve iş kuralını birlikte yönettiği ürünlerde uyumludur. Oturum tablosu, Redis benzeri bir depo veya çatı oturumu fark etmez: durum sizin tarafınızda durur. “Bu oturum hâlâ geçerli mi?” sorusunun cevabı belgede değil, kayıtta aranır.
Tarayıcıda oturumu güçlendiren pratikler abartılı bir yığın olmak zorunda değildir. Oturum kimliğini betiğin okuyamayacağı bir çerezde tutmak, çerezin hangi sitede gideceğini daraltmak ve tarayıcının otomatik gönderdiği kanıt için sahte istek koruması planlamak çoğu üründe yeterli çerçevedir. Ayrıntı tehdit modeline göre değişir; çerçeve değişmez: tarayıcı kanıtı otomatik taşır, sunucu onu sahiplenir.
Oturumun bedeli vardır. Sunucu durumu tutar. Birden fazla uygulama sunucusu varsa deponun paylaşılması gerekir. Bu bedel, “mikroservise geçiyoruz” cümlesiyle abartılmamalıdır. Tek bir iş uygulaması, tek bir oturum deposu ve tarayıcı paneli için bu maliyet genelde yönetilebilir kalır. Ölçek sorunu gerçekten oturumdan geliyorsa model değiştirilir; moda olduğu için değil.
JWT hangi istemcide işe yarar
JWT, kanıtı istemcinin taşıdığı ve birden fazla hizmetin aynı imzayı doğrulayabildiği yerde anlam kazanır. Mobil uygulama, harici entegrasyon ve sizin tarayıcınız olmayan tüketiciler bu sınıfa girer. Sunucu her istekte oturum kaydına bakmak zorunda kalmadan kimliği ve sınırlı iddiaları okuyabilir.
Anlam kazandığı yer, oturumun yerini “otomatik” aldığı yer değildir. JWT bir oturum kaydının kopyası değildir. İçindeki iddialar imzalandığı andaki gerçeği taşır. Kullanıcı yetkisi düştüyse, cihaz çalındıysa veya çıkış yapıldıysa imzalı belge kendi kendine geçersiz olmaz. Bunu görmezden gelen ekip, JWT’yi sonsuz bir giriş bileti sanır.
API tüketicisinde işe yarayan düzen genellikle şöyledir: kısa ömürlü erişim belgesi, daha sıkı korunan bir yenileme belgesi, yenilemenin sunucuda izlenmesi ve şüphede tüm zincirin kesilmesi. Bu düzen “stateless” vaadini yumuşatır. Bir miktar sunucu durumu geri gelir. Geri gelmesi kusur değil, iptalin bedelidir.
Tarayıcıdaki tek sayfalık arayüzde JWT’yi varsayılan yapmak da aynı tuzağa düşer. Arayüz sizin origin’inizdeyse, kanıtı JavaScript’in okuyabildiği bir depoya koymak tarayıcı tehdit yüzeyini büyütür. Bu durumda tarayıcıya özel bir arka uç katmanı oturumu çerezle tutup API’ye sunucu tarafında konuşmak, moda token’dan daha sakin bir çözümdür. KepezWeb bu ayrımı yazılım geliştirme işlerinde istemci haritası olarak çizer: tarayıcı bir kapı, API başka bir kapı.
Oturum ve JWT’yi yan yana okuyun
Aşağıdaki tablo kazanan ilan etmez. İstemci türüne göre hangi yükün kime ait olduğunu gösterir.
| Karar ölçütü | Oturum | JWT |
|---|---|---|
| Durumun durduğu yer | Sunucu kaydı | İmzalı belge; iptal için ek kayıt gerekebilir |
| Doğal istemci | Aynı sitedeki tarayıcı | API tüketicisi, mobil, servis çağrısı |
| Çıkış ve iptal | Kaydı silmek veya düşürmek | Süre, yenileme izi veya geçersiz listesi |
| Yetki değişince | Sonraki istek kaydı okur | Eski belge süre bitene kadar iddiayı taşıyabilir |
| Ölçek yükü | Oturum deposu paylaşımı | Doğrulama dağılabilir; iptal maliyeti geri gelir |
| Taşıyıcı | Çerezle uyumlu | Başlıkla uyumlu; tarayıcıda ayrı tasarım ister |
Tablodaki asıl ders şudur: “stateless” ucuzluk vaadi, iptali erteleyen bir muhasebedir. Oturum deposu bugün maliyet görünür. JWT’de görünmeyen maliyet, çıkışın ve yetki düşürmenin sonraya bırakılmasıdır. Ürün bu maliyeti kaldırabiliyorsa JWT yerinde durur. Kaldıramıyorsa oturum daha dürüst bir modeldir.
Aynı üründe iki modeli birlikte kullanmak
Birçok iş yazılımı tek seçim zorlamasına gerek duymaz. Yönetim paneli tarayıcıda oturumla çalışır. Aynı iş kuralları mobil uygulamaya kısa ömürlü erişim belgesiyle açılır. Partner entegrasyonu ise kullanıcı oturumu değil, dar kapsamlı bir servis kimliği kullanır. Üç kapı aynı kullanıcı tablosuna bakabilir. Kapıların kilidi aynı olmak zorunda değildir.
Birlikte kullanımın kuralı sadedir. Tarayıcı kanıtını API tüketicisinin belgesiyle karıştırmayın. Paneden kopyalanan bir JWT’yi çerezin yerine koymayın. Mobil yenileme belgesini tarayıcı deposuna taşımayın. Ortak olan kimlik kaydıdır; ortak olmayan taşıyıcı, ömür ve iptal yoludur.
Bu ayrım, ileride yeni bir istemci eklendiğinde de işe yarar. Pazaryeri entegrasyonu, saha uygulaması veya başka bir yazılımın sizi çağırması geldiğinde “zaten JWT’miz var” diye her kapıyı aynı anahtarla açmazsınız. Her kapıya kendi ömrünü ve kendi iptalini verirsiniz. Kimlik verisi tek, kanıt modeli çoğul kalır.
Seçim için uygulanabilir kontrol listesi
Kararı toplantıda kütüphaneye bakarak vermeyin. Aşağıdaki sırayı ürün üzerinde yürütün. Cevaplar netleşince model de netleşir.
- İstemciyi yazın: tarayıcı paneli, mobil uygulama, sunucudan sunucuya çağrı, üçüncü taraf. Birden fazla varsa her birini ayrı satıra alın.
- Her istemci için çıkış senaryosunu yazın. Kullanıcı çıkış yaptığında, şifre değiştirdiğinde ve cihaz kaybolduğunda kanıt kaç saniye daha geçerli kalabilir?
- Yetki düşürmeyi yazın. Bir rol daraldığında tarayıcıdaki sonraki tıklama ve API’deki sonraki çağrı yeni gerçeği ne zaman görür?
- Kanıtın kim tarafından gönderildiğini yazın. Tarayıcı otomatik mi ekliyor, istemci bilinçli mi başlığa koyuyor?
- Durum deposunu kabul edin veya reddedin. Oturum tablosu, yenileme kaydı veya geçersiz listesi yoksa iptal de yoktur.
- Tarayıcı tehdit yüzeyini ayrı tutun. Betiğin okuyabildiği depo, tarayıcı uygulaması için varsayılan yer değildir.
- Servis kimliği ile kullanıcı kimliğini ayırın. Entegrasyon anahtarı, personel oturumu değildir.
- Kararı istemci satırına işleyin. Tek cümlelik “artık JWT kullanıyoruz” notu mimari sayılmaz.
Bu liste bir çerçeve seçtirir, kütüphane seçtirmez. Çerçeve oturumsa tarayıcıda sade tutun. Çerçeve JWT ise ömrü kısa tutun ve yenilemeyi izleyin. İkisi birden varsa kapıları karıştırmayın. Uygulama bu kadar somuttur; geri kalanı tartışma süsüdür.
Sıkça Sorulan Sorular
SPA yazıyorsam jwt vs session tartışmasında JWT zorunlu mu?
Hayır. Tek sayfalık arayüz sizin origin’inizde çalışıyorsa tarayıcıya özel bir arka uç, oturumu çerezle tutup API’ye sunucu tarafında konuşabilir. JWT, SPA olduğu için değil, tarayıcı olmayan bir tüketiciniz olduğu için gündeme gelir.
JWT oturumun yerini tamamen alır mı?
Almaz. JWT imzalı bir andaki iddiayı taşır. Oturum ise “şu an geçerli mi?” sorusunu kayıttan cevaplar. Çıkış, cihaz iptali ve yetki düşürme sizin için kritikse JWT’nin yanına bir durum mekanizması eklenir; o noktada saf bir yerine geçme kalmaz.
Aynı kullanıcı hem panele hem mobil uygulamaya giriyorsa ne yapmalı?
Kullanıcı kaydı ortak, kanıt ayrı olsun. Panel tarayıcı oturumuyla çalışabilir. Mobil istemci kısa ömürlü erişim belgesi ve izlenen yenileme kullanabilir. Birinin çıkışı diğerini ancak sizin yazdığınız kural kadar etkiler; bunu açıkça kararlaştırın.
Hangisi daha güvenli: oturum mu JWT mi?
Hiçbiri kendi başına daha güvenli değildir. Güvenlik, kanıtın nerede durduğu, kimin okuyabildiği, ne kadar yaşadığı ve nasıl iptal edildiğiyle kurulur. Yanlış yerde tutulan JWT ile iptali unutulmuş bir oturum aynı işi bozar.
Mikroservise geçince oturumu bırakmak gerekir mi?
Gerekmez. Hizmetler çoğalsa bile tarayıcı paneli tek bir giriş katmanının arkasında kalabilir. Dağıtık API tüketicisi yoksa JWT’ye geçmek mimari zorunluluk değil, ekstra iptal işidir. Önce istemci haritasına bakın.
Kimlik modeli, ekran tasarımından önce çizilmesi gereken bir ürün sınırıdır. Tarayıcı uygulaması ile API tüketicisini ayırdığınızda jwt vs session tartışması sakinleşir; geriye istemci, iptal ve ömür kalır. KepezWeb ile bu sınırı yazılımınıza göre netleştirmek isterseniz teklif al sayfasından ihtiyacınızı yazın. İstemci haritasını birlikte okuyup tarayıcı kapısı ile API kapısını ayrı kararlaştıralım.
