Related Articles

Kubescape Nedir? Açık Kaynak Kubernetes Güvenlik Platformu Rehberi

5 gün ago

Kartla Ödeme Nasıl Çalışır? “Ödeme Başarılı” Mesajının Arkasında Ne Var?

5 gün ago

Grype Nedir? Container ve SBOM Zafiyet Tarama Rehberi

2 hafta ago

Kimlik Doğrulamada Bu 3 Yapı Ne İşe Yarar?

Web uygulamalarında kimlik doğrulama denildiğinde en çok karıştırılan üç kavram vardır:

Cookie, Session ve Token.

Bu üç yapı birbirinin birebir alternatifi değildir. Aslında farklı katmanlarda görev alırlar:

• Cookie, tarayıcıda veri saklama ve her istekte sunucuya gönderme mekanizmasıdır.
• Session, kullanıcı oturum bilgisinin sunucu tarafında tutulduğu modeldir.
• Token/JWT, kimlik veya yetki bilgisini imzalı şekilde taşıyan doğrulama yapısıdır.

Doğru mimariyi seçmek için önce bu farkı net anlamak gerekir.

---

🍪 Cookies — Tarayıcı Taraflı Hafıza

Cookie, web sunucusunun kullanıcının tarayıcısında küçük veri parçaları saklamasını sağlayan mekanizmadır.

Tarayıcı, ilgili domain’e yapılan sonraki isteklerde bu cookie’yi otomatik olarak sunucuya gönderir.

Nerede Kullanılır?

Cookie’ler genellikle şu amaçlarla kullanılır:

• Oturum ID’si saklama
• Kullanıcı tercihleri
• Dil seçimi
• Tema seçimi
• Sepet bilgisi
• Tracking / analytics
• CSRF token taşıma
• “Beni hatırla” işlevi

Örnek Cookie Header

Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax; Path=/

Kritik Güvenlik Ayarları

HttpOnly

JavaScript’in cookie’ye document.cookie üzerinden erişmesini engeller. Bu ayar özellikle XSS sonrası session cookie çalınmasını zorlaştırır.

Secure

Cookie’nin yalnızca HTTPS üzerinden gönderilmesini sağlar. HTTP üzerinden taşınmasını engeller.

SameSite

Cross-site isteklerde cookie’nin gönderilip gönderilmeyeceğini kontrol eder. CSRF riskini azaltmak için önemlidir.

Genel yaklaşım:

SameSite=Strict  → en sıkı model
SameSite=Lax     → çoğu klasik web uygulaması için dengeli model
SameSite=None    → üçüncü taraf/cross-site kullanım gerekir; Secure ile birlikte kullanılmalı

---

🧠 Sessions — Sunucu Taraflı Oturum Yönetimi

Session modelinde kullanıcının oturum verisi sunucu tarafında tutulur. Tarayıcıda genellikle sadece bir session ID yer alır.

Yani kullanıcıya ait asıl bilgiler client tarafında değil, sunucudaki session store içinde saklanır.

Session Akışı

Kullanıcı login olur
→ Sunucu session oluşturur
→ Kullanıcıya session_id içeren cookie döner
→ Tarayıcı sonraki isteklerde session_id gönderir
→ Sunucu session_id ile kullanıcıyı tanır

Avantajları

• Hassas oturum verisi tarayıcıda tutulmaz.
• Logout sonrası session sunucudan iptal edilebilir.
• Yetki değişiklikleri hızlı uygulanabilir.
• Revocation daha kolaydır.
• Klasik web uygulamaları için güçlü ve anlaşılır modeldir.

Dikkat Edilmesi Gerekenler

Session güvenliğinde en kritik başlıklar:

• Session ID tahmin edilemez olmalı
• Login sonrası session ID yenilenmeli
• Logout sonrası session geçersiz kılınmalı
• Idle timeout ve absolute timeout tanımlanmalı
• Session fixation saldırılarına karşı önlem alınmalı
• Session store güvenli ve yüksek erişilebilir olmalı

Ölçeklendirme Zorluğu

Session modeli sunucu tarafında state tuttuğu için büyük sistemlerde ek tasarım gerektirir.

Örnek ihtiyaçlar:

• Redis / Memcached gibi merkezi session store
• Load balancer üzerinde sticky session veya paylaşımlı store
• Session replication
• High availability
• Session cleanup politikası

---

🔐 Tokens / JWT — Taşınabilir ve İmzalı Doğrulama

Token, kullanıcının kimlik veya yetki bilgisini taşıyan doğrulama nesnesidir. En bilinen formatlardan biri JWT — JSON Web Token’dır.

JWT genellikle üç parçadan oluşur:

Header.Payload.Signature

JWT İçinde Ne Olur?

JWT içinde genellikle “claim” adı verilen bilgiler bulunur:

• Kullanıcı ID
• Rol
• Yetki bilgisi
• Issuer
• Audience
• Expiry
• Token üretim zamanı
• Scope bilgisi

Neden Tercih Edilir?

JWT özellikle şu senaryolarda yaygındır:

• REST API
• Mobil uygulama
• Mikroservis mimarisi
• OAuth2 / OpenID Connect akışları
• Dağıtık servisler
• Stateless authorization ihtiyaçları

Kritik Güvenlik Noktaları

JWT kullanırken dikkat edilmesi gerekenler:

• Access token kısa ömürlü olmalı
• Refresh token ayrı ve daha güvenli yönetilmeli
• Token imzası mutlaka doğrulanmalı
• alg:none gibi zayıf/yanlış doğrulama hatalarına izin verilmemeli
• iss, aud, exp, nbf claim’leri kontrol edilmeli
• Token içinde hassas veri tutulmamalı
• Public/private key doğrulaması doğru yapılmalı
• Key rotation planı olmalı
• Logout ve token revocation stratejisi tasarlanmalı

Önemli Not

“JWT stateless olduğu için sunucuda hiçbir şey tutmaya gerek yok” ifadesi her zaman doğru değildir.

Evet, access token doğrulaması stateless yapılabilir. Ancak gerçek dünyada şu ihtiyaçlar doğar:

• Refresh token saklama
• Token iptali
• Logout sonrası erişimi kesme
• Çalıntı token riskini azaltma
• Kullanıcı yetkisi değişince token etkisini yönetme
• Riskli oturumu sonlandırma

Bu nedenle kritik sistemlerde JWT mimarisi genellikle tamamen stateless değil, kontrollü ve revocation destekli hybrid model olarak tasarlanır.

---

🎯 Ne Zaman Hangisini Kullanmalı?

🌐 Klasik Web Uygulamaları

En yaygın ve güvenli yaklaşım:

Cookie + Server-side Session

Uygun olduğu yerler:

• Kurumsal web uygulamaları
• Yönetim panelleri
• E-ticaret sistemleri
• İç portal uygulamaları
• CSRF koruması gereken browser tabanlı sistemler

---

⚙️ Mobil API ve Mikroservisler

Yaygın yaklaşım:

Access Token + Refresh Token

Uygun olduğu yerler:

• Mobil uygulamalar
• REST API
• Mikroservisler
• OAuth2 / OIDC
• API Gateway mimarisi
• Service-to-service authorization

---

🧩 Karma Sistemler

Birçok modern sistemde hybrid model kullanılır.

Örnek:

Web frontend → Secure + HttpOnly cookie
API access   → Short-lived access token
Refresh      → Güvenli saklanan refresh token
Session risk → Server-side revocation / token blacklist

Bu yapı, hem kullanıcı deneyimini hem de güvenlik kontrolünü dengeleyebilir.

---

⚠️ Cookie vs Session vs Token Karşılaştırması

Başlık	Cookie	Session	Token / JWT
Nerede tutulur?	Tarayıcıda	Sunucuda	Client tarafında veya güvenli storage’da
Ne taşır?	Küçük veri / session ID	Kullanıcı oturum verisi	Claim ve yetki bilgisi
Her istekte gider mi?	Evet, otomatik	Session ID cookie ile gider	Header veya cookie ile gönderilir
Stateful mı?	Kendisi değil	Evet	Genellikle stateless
Logout kontrolü	Cookie silinir	Session iptal edilir	Revocation tasarımı gerekir
En uygun kullanım	Web	Klasik web oturumu	API / mobil / mikroservis
Ana risk	XSS/CSRF/cookie theft	Session hijacking/fixation	Token theft/replay/revocation zorluğu

---

✅ Güvenli Tasarım Checklist

Cookie için

• HttpOnly kullan
• Secure kullan
• SameSite=Lax veya Strict tercih et
• Gereksiz domain genişliği verme
• Hassas veriyi cookie içinde düz metin tutma
• Cookie ömrünü sınırlı tut
• HTTPS zorunlu olsun

Session için

• Güçlü ve rastgele session ID üret
• Login sonrası session ID yenile
• Logout sonrası session’ı iptal et
• Idle timeout tanımla
• Absolute timeout tanımla
• Session store’u merkezi ve güvenli yönet
• Session fixation kontrollerini uygula

Token / JWT için

• Access token kısa ömürlü olsun
• Refresh token güvenli saklansın
• İmza doğrulaması zorunlu olsun
• issuer ve audience kontrol edilsin
• Algoritma sabit ve güvenli seçilsin
• Token içinde parola, TCKN, kart bilgisi gibi hassas veri tutma
• Revocation / blacklist / token rotation planı yap
• Key rotation süreci belirle

---

⚡ 48s Mini-PoC Planı

1. Mevcut login akışında cookie/session/token nerede kullanılıyor çıkarın.
2. Browser DevTools ile cookie flag’lerini kontrol edin.
3. HttpOnly, Secure, SameSite eksiklerini listeleyin.
4. Session ID’nin login sonrası değişip değişmediğini test edin.
5. Logout sonrası eski session/token ile erişim denenmesini kontrol edin.
6. JWT varsa exp, iss, aud, alg kontrollerini doğrulayın.
7. Refresh token storage ve rotation modelini inceleyin.
8. Riskleri “yüksek / orta / düşük” olarak raporlayın.

---

Sonuç

Cookie, Session ve Token aynı şey değildir.

Cookie, tarayıcı ile sunucu arasında veri taşıyan mekanizmadır.
Session, sunucu tarafında oturum bilgisini yöneten modeldir.
Token/JWT, kimlik ve yetki bilgisini imzalı şekilde taşıyan doğrulama yapısıdır.

Güvenli kimlik doğrulama mimarisi, bu üç yapıyı doğru yerde ve doğru güvenlik kontrolleriyle kullanmaktan geçer.