Session lifecycle, login ve logout

Cookie taşıyıcıdır; session kararı server’da yaşar

Duru, Atlas kitaplığına login olduktan sonra ikinci sayfayı açar. Bu yeni HTTP request ilk login işleminin hafızasını taşımaz. Browser uygun cookie’yi request’e ekler; application ise aldığı identifier’ı session store’da kontrol eder. Bu örnekte cookie bir opaque handle taşır: kimliğin, authentication durumunun ve sürelerin anlamı server kaydındadır. Cookie değerinin bulunması tek başına geçerli session olduğunu göstermez.

Üç ayrı alanı izle: Browser cookie jar identifier’ı saklar. Application her korumalı request için kabul kararını verir. Session store aktif kaydı ve lifecycle state’ini tutar. Store aynı process içindeki memory de olabilir, paylaşılan persistence da; çizimde ayrı görünmesi zorunlu olarak ayrı network servisi olduğu anlamına gelmez.

Ön bilgi: WEB-12.01/12.02 cookie anatomy; WEB-13.01/13.02 identifier ve store ayrımı. Bu dersin kısa primer’ı şudur: Set-Cookie bir response header’dır, Cookie sonraki request’in taşıdığı name/value çiftleridir. Cookie attributes request’te tekrar listelenmez; application bunları Cookie header’dan okuyarak güvenlik garantisi çıkaramaz.

Login iki tarafta aynı anda gerçekleşmez

İlk sahnede Browser sid-a etiketiyle gösterilen anonymous session’a sahiptir. Duru’nun kimliğinin doğrulandığı t=10 anında application sid-b olarak çizilen yeni authenticated session generation’ı oluşturur; eski anonymous identifier authenticated kimliğe yükseltilmez. sid-a ve sid-b eğitim etiketidir, kullanılabilir credential veya üretim identifier formatı değildir.

Modelde server kaydı güncellendikten sonra Set-Cookie response’u yola çıkar. Response Browser’a henüz ulaşmadıysa store yeni generation’ı tanır, cookie jar ise hâlâ eski etiketi tutar. Arrival adımında Browser cookie’yi kabul eder. Bu ara durum bir animasyon detayı değildir: bağlantı koparsa server transition tamamlandığı hâlde client yeni identifier’ı alamamış olabilir.

Burada rotation sırasında eski generation hemen geçersizleşir. Eşzamanlı request’lerin olduğu gerçek uygulamalarda geçiş davranışı ayrıca tasarlanır; framework’ün migration ve invalidation sözleşmesi incelenir. Authentication öncesi identifier’ın hangi koşulda kabul edildiği ile privilege değişimi sonrasındaki identifier aynı mesele değildir.

Korumalı request: lookup, süre kontrolü, ardından resource policy

Duru t=70’te bir kitap kaydını açar. Browser’ın cookie inclusion kuralları uygun identifier’ı application’a taşır. Application store kaydını bulur, generation’ın active olduğunu ve süre sınırlarının geçilmediğini kontrol eder. Bu örnekte check başarılı olunca lastSeen=70 olur. Hangi request’lerin activity sayılacağı uygulama policy’sidir; background polling’in her zaman kullanıcı faaliyeti sayılması gerekmez.

Session kabulü bir authenticated subject üretir; resource authorization ayrı karardır. Duru’nun identity’sinin bulunması başka tenant’ın kitabını okuma yetkisi oluşturmaz. WEB-14.05 bu sonraki subject/action/object/context kararını açar. Bu dersin modeli session rejected ise protected işleme geçmez; kabul edildiğinde de resource policy’yi atlamaz.

Lookup sonucu yoksa, kayıt revoked ise veya süre bitmişse aynı yeşil “logged in” UI’ı kararı değiştiremez. Örnek application yeniden login gerektirir. HTTP status ve redirect davranışı endpoint sözleşmesine bağlıdır; bütün expiry durumları için tek evrensel response kodu yoktur.

Üç saat aynı şey değildir

Örneğin policy’si idle=300 saniye ve absolute=1800 saniyedir. Bunlar öğretim için seçilmiş sayılardır, her ürüne önerilen güvenlik ayarı değildir. Login t=10’da yeni session oluşturur; absolute deadline=1810 olur. t=70’teki kabul edilmiş işlemden sonra idle deadline=370 olur. t=370 sınırında now−lastSeen >= 300 olduğu için yeni request reddedilir; o request lastSeen’i ilerletip kendisini kurtaramaz.

Idle süre son kabul edilen activity’ye göre yürür. Absolute süre session’ın başlangıcından yürür; activity’nin artması onu ileri taşımaz. Identifier rotation tek başına yeniden authentication veya sonsuz session ömrü değildir: sürelerin yeniden başlatılıp başlatılmayacağı ayrı policy kararıdır.

Cookie Max-Age=1800 ise Browser’ın identifier’ı saklama süresini anlatır. Server’ın idle kontrolü cookie daha jar’da dururken session’ı geçersiz sayabilir. Cookie’nin erken silinmesi ise server kaydını otomatik silmez. Expires ile Max-Age birlikteyse Max-Age önceliklidir; attributes bulunmayan session cookie için Browser session restore davranışı da hesaba katılır.

Logout: server invalidation ve cookie temizliği

Logout branch’i t=70’teki geçerli session’dan ayrılır. Duru t=90’da logout seçer. Application current generation’ı revoked yapar; ardından Browser’a aynı cookie name, Path ve varsa Domain scope’u için Max-Age=0 gönderir. Server invalidation, response receipt ve cookie jar temizliği farklı transitions olarak çizilir.

Response kaybolursa Browser eski cookie’yi tutabilir; server revoked kaydı kabul etmez. Browser’ın yalnız cookie’yi silmesi ters durumu yaratır: client handle’ı bırakmış olur, server state’in iptal edildiği bundan çıkarılamaz. UI’da logout mesajı görünmesi veya bir sekmenin kapanması da server invalidation kanıtı değildir.

Bu branch yalnız current session generation’ını kapatır. “Bütün cihazlardan çıkış”, password değişimi veya federated identity provider logout’u daha geniş policy ve yayılım gerektirebilir. Çok node’lu bir sistemde invalidation’ın hangi store/cache okumasına ne zaman yansıdığı da logout garantisinin parçasıdır.

Cookie flags farklı sınırları korur

Synthetic HTTPS örneğinde __Host-hd_session; Path=/; Secure; HttpOnly; SameSite=Lax kullanılır ve Domain verilmez. __Host- kuralını destekleyen Browser bu isim için Secure, host-only scope ve Path=/ koşullarını arar. Prefix bütün Browser sürümleri için otomatik uyumluluk garantisi sayılmaz.

Secure taşıma kanalını, HttpOnly script ile cookie erişimini, SameSite cross-site inclusion koşullarını etkiler. Hiçbiri store’daki revoked kaydı active yapmaz veya resource authorization sağlamaz. Path bir gönderim filtresidir; aynı host içindeki uygulamalar arasında sağlam bir güvenlik izolasyonu gibi kullanılmaz.

HttpOnly cookie’nin değeri document.cookie üzerinden görünmez; buna karşın uygun JavaScript kaynaklı request’lere cookie eklenebilir. Frontend fetch response’u üzerinden Set-Cookie header’ını okumak da beklenen yöntem değildir. DevTools cookie ve network gözlemi ile application log’u farklı erişim ve kanıt yüzeyleridir.

Self-contained token’a geçince logout sorusu değişir

Opaque handle modelinde application her kabul kararını server state’e bağlar. Self-contained token kullanan bir tasarımda verifier signature ve beklenen issuer/audience/time koşullarını kendi başına değerlendiriyorsa, Browser’ın token’ı silmesi o verifier’a yeni bir iptal bilgisi göndermez. Geçerli kriptografi ile güncel kullanım yetkisi farklı sorulardır.

JWT exp claim’i varsa token o zaman ve sonrasında kabul edilmez; clock-skew toleransı ve zorunlu claim set’i kullanılan profile’a bağlıdır. “JWT zaten stateless, logout olamaz” genellemesi de yanlıştır. Bir tasarım revocation state, session version, introspection veya kısa access-token ömrü kullanabilir; bunun state, communication ve gecikme maliyeti vardır.

Refresh token’ın iptali yeni access token alınmasını durdurabilir; hâlihazırdaki access token’ın bütün resource server’larda aynı anda iptal edildiği ayrıca kanıtlanmalıdır. Refresh-token rotation ile bu dersin Browser session identifier rotation’ı farklı mekanizmalardır. WEB-14.03/14.S03 ve WEB-15 identity dersleri token doğrulaması ve delegation ayrıntılarını açar.

Authentication öncesi state neden ayrı tutulur?

Normal akışta anonymous session kişiselleştirme veya geçici UI state taşıyabilir; authenticated session ise Duru’nun identity’sini korumalı işlemlere bağlar. İkinci state’in authority’si, birinci identifier’ın kim tarafından seçildiği veya daha önce nerede kullanıldığına güvenilerek kurulmaz.

Bozulan varsayım şudur: “Login başarılıysa mevcut identifier artık güvenilir.” Authentication kontrolü credential doğrularken eski handle’ın geçmişini kendiliğinden değiştirmez. Login veya önemli privilege değişiminde yeni generation’a geçmek ve eski generation kabulünü kapatmak, bu iki güven düzeyinin birbirine karışmasını önler. Riskin kapsamı session’ın sağladığı identity ve izinlerle sınırlıdır; her session hatası bütün sistemi ele geçirme sonucu doğurmaz.

Cookie’yi korumak ile session’ı geçersizleştirmek ayrı kontrollerdir

Bir identifier authenticated state’e ulaşmak için yeterli bir bearer handle olarak kullanılıyorsa, gizliliği önemlidir. Uygun HTTPS taşıması ve dar cookie scope’u maruz kalma yüzeyini azaltır. HttpOnly bir script’in değeri okumasını sınırlar; Browser’ın o script kaynaklı uygun işlemlerde identity’yi taşımasını tek başına durdurmaz.

Bu nedenle “HttpOnly var” sonucundan işlem güvenliği, CSRF kontrolü veya resource authorization sonucu çıkarılmaz. Kontrol bozulan boundary’ye yerleştirilir: taşıma için kanal, script erişimi için cookie özelliği, state-changing action için request doğrulaması, object erişimi için server policy. Bu derste payload üretmek yerine hangi kontrolün hangi varsayımı karşıladığını ayırıyoruz.

Süresi bitmiş veya revoked handle neden kabul edilmemeli?

Modelde t=370’te cookie görünür olabilir ama session artık idle koşulunu sağlamaz. Kontrolün UI timer’a bırakılması server kararını client’ın görünümüne bağlar. Benzer biçimde logout yalnız jar’ı temizliyorsa server’daki authority devam edebilir. Kalıcı kontrol, protected işlemin kabul noktasında current generation ve server deadline değerlendirmesidir.

Self-contained bir tasarımda aynı sorunun cevabı revocation dağıtımına bağlıdır. Bir node signature ve exp dışında hiçbir güncel state okumuyorsa, başka node’da yapılan logout onun kararını hemen değiştirecek bilgi taşımamış olabilir. Engelleyici tasarımın hangi gecikme penceresini kabul ettiği ve bunu hangi observable kontrolle doğruladığı açık olmalıdır.

Hangi gözlem hangi state’i kanıtlar?

DevTools Network’te Set-Cookie görmek application’ın bir header gönderdiğini gösterir; Browser’ın cookie’yi kabul ettiğini ayrıca cookie storage ve ilgili request inclusion üzerinden değerlendirirsin. Policy, scope veya Browser ayarları kabulü değiştirebilir. Cookie görünümü server store’un active olduğunu; UI kimlik etiketi de son protected kararın başarılı olduğunu tek başına kanıtlamaz.

Bu dersin ledger’ı application-owned sentetik JSON’dur. Standart bir web server’ın hazır event adı, SIEM tablosu veya gerçek packet capture diye sunulmaz. event, seq, clock_s, generationRef, requestId, result ve reason alanları bizim fixture şemamızdır. Gerçek uygulamada event’in üretildiği code path ve log delivery davranışı ayrıca belgelenir.

Credential içermeyen lifecycle correlation

Rotation, expiry ve logout’u ilişkilendirmek için audit correlation ref kullan; raw session value, Set-Cookie value veya credential loglama. Bu fixture’da generationRef=ledger-b bir audit referansıdır, Browser handle’ına dönüştürülemez. requestId=demo-session-3 yalnız aynı check’in application ve karar kaydını eşler.

Korelasyon sorusu nettir: Aynı generationRef için terminal transition’dan sonra session_check accepted var mı? Artifact’te KQL, embedded datatable üstünde seq alanını kullanır. Bu seq yalnız tek model senaryosundaki sıralamadır; dağıtık host’ların wall-clock timestamp’lerini evrensel sıraya çevirmez. Shared session bütünlüğü için gerçek event ordering ve node/store consistency ayrıca incelenir.

Idle branch’inde t=70 accepted check ve t=370 expired/rejected check normaldir; sorgu satır üretmez. Terminal transition’dan sonra accepted check eklenmiş pozitif bir fixture kontrol eksikliğini gösterebilir. Eksik terminal event ise kabul edildiğinin değil, kanıtın eksik olduğunun işaretidir. Log delivery kesintisi, duplicate event veya yanlış generationRef eşlemesi gerçek ortamda değerlendirilmeden bir satıra saldırı etiketi konmaz.

Doğrulama ve kalıcı kontrol

Manual labda sırayla login öncesi/sonrası jar state’ini, sanitized store görünümünü, explicit demo clock expiry’sini ve logout sonrası protected kararı gözle. Önce sonucu tahmin et, sonra hangi katmanda gözlemlediğini yaz. Store invalidation ile response arrival ayrıysa bu iki adımın arasındaki görünümü de açıklayabilmelisin.

Üretim hardening kararı verirken framework session lifecycle davranışını, HTTPS/proxy yapılandırmasını, cookie scope’unu ve uygulamaya uygun idle/absolute policy’yi birlikte ele al. Geçişi kontrollü kullanıcı grubunda doğrula; uzun form, background activity ve çok sekmeli kullanımın uyumluluk etkisini ölç. Değişen role veya account state’in mevcut session’lara nasıl yansıyacağını ayrıca belirle.

Bu dersin kabul ölçütü her göstergenin yeşil olması değil: Browser jar temiz, store revoked ve protected check rejected durumlarının hangi bağımsız kanıta dayandığını açıklayabilmek. KQL burada açıklamalı inceleme mantığıdır; gerçek ingest veya detection backend kurulumu, sırf sorgu metni bulunduğu için yapılmış sayılmaz.

Login veya privilege değişiminde session identifier’ını server’da yenile; eski generation’ın korumalı işlemlerde kabulünü kapat. Idle ve absolute deadline’ı her korumalı request’te trusted server state üzerinden uygula; Browser cookie expiry’sini bu kontrolün yerine koyma. Logout’ta önce ilgili server kaydını geçersizleştir, ardından cookie temizleme talimatını gönder. “Bu session” ile “bütün cihazlar” kapsamını açıkça ayır. Rotation sonrası eski generation, deadline eşitliği ve logout sonrası eski handle için ret bekle; terminal kayıt eksikse global revoke sonucu çıkarma.