Login ve Oturum Mimarisi: Güvenlik Perspektifi

  1. Anasayfa
  2. Blog
  3. Yazılım Geliştirme
  4. Login ve Oturum Mimarisi: Güvenlik Perspektifi

Güvenli login ve oturum yönetimi nasıl tasarlanır? AES şifreleme, JWT, refresh token yenileme, CSRF, OTP ve session koruması ile eksiksiz çözüm. 

 

1. Genel Mimari Bakış Token'lar UI tarafında kesinlikle saklanmaz (LocalStorage / SessionStorage kullanılmaz). 

  • Sadece sunucu tarafında, AES-256-GCM ile şifrelenmiş bir session store (tercihen Redis) tutulur. 

  • Kullanıcı tarafına yalnızca HttpOnly + Secure + SameSite=Strict cookie gönderilir. 

  • Tüm iletişim HTTPS üzerinden yapılır ve HSTS (HTTP Strict Transport Security) aktif olmalıdır. 

  • Session şifreleme anahtarları, KMS (Key Management Service) veya HSM (Hardware Security Module) üzerinden yönetilmelidir. Anahtarlar periyodik olarak rotasyona tabi tutulmalıdır. 

2. Token ve Session Birlikte Neden Kullanılır ?  

Amaç 

Neden 

Güvenlik 

UI token'lara erişemez → XSS riski minimize edilir. 

Performans 

UI sade cookie taşır, token kontrolü sunucuda yapılır. 

Otomasyon 

Token süresi %80 dolduğunda otomatik yenileme yapılır. 

 

3. Login Akışı 

  1. [UI] → POST /api/auth/login 

  1. [API] → Kimlik doğrulama (kullanıcı + şifre) 

  1. JWT (RS256 imzalı access token) + Refresh token üretilir. 

  1. Token’lar, AES-256-GCM ile sunucu tarafında şifrelenir. 

  1. Session store (Redis) içine yazılır. 

  1. Kullanıcıya sadece HttpOnly + Secure cookie döndürülür (__Host- prefix ile). 

  1. Redis key’ler otomatik olarak TTL (örneğin 24 saat) ile expire olacak şekilde ayarlanır. 

Şekil 

4. Token Yaşam Döngüsü ve Yenileme 

  • Access Token: 24 saat geçerlidir (idle-based timeout). 

  • Refresh Token: 7 gün geçerlidir. Her yenilemede rotasyon uygulanır. 

  • Eski refresh token anında geçersiz kılınır (token reuse engellenir). 

  • Token süresi %80’e ulaştığında, arka planda güvenli yenileme isteği gönderilir. 

  • Bu yenileme isteği mutlaka: 

  • Session doğrulaması yapmalı. 

  • Replay saldırılarını önlemek için nonce veya jti kontrolü içermelidir. 

Şekil 

5. OTP (Tek Kullanımlık Şifre) Akışı 

  • Yeni cihaz, şüpheli IP, yüksek yetkili hesap veya olağandışı davranış tespitinde zorunludur. 

  • Risk temelli bir sistem tarafından tetiklenir. 

  • OTP doğrulanmadan token oluşturulmaz. 

  • Ek güvenlik önlemleri: 

  • OTP deneme limiti (örneğin 5 hatalı girişte hesap kilidi) 

  • OTP gönderim aralığı (örneğin 30 saniyede bir) 

  • OTP log’larında masking (örneğin ****1234) 

Şekil 

6. Logout / Oturum Sonlandırma 

  • Kullanıcının session’ı Redis’ten silinir. 

  • Token, revocation list veya blocklist içine eklenir. 

  • Cookie temizlenir. 

  • Bu işlem loglanır: IP, kullanıcı ID, zaman bilgisiyle. 

Şekil 

7. Session Güvenliği 

  • Her session, cihaz fingerprint’i (IP, User Agent, platform) ile ilişkilendirilir. 

  • IP veya cihaz değişirse oturum sonlandırılır. 

  • Session şifrelemesi AES-GCM ile yapılmalı; IV + salt kombinasyonu kullanılmalıdır. 

  • Redis session anahtarları rastgele UUID (örneğin session:{uuidv4()}) şeklinde tutulmalıdır. 

Şekil 

8. Token Güvenliği 

  • JWT, RS256 (asimetrik anahtar) ile imzalanır. 

  • Alanlar: iss, sub, aud, exp, iat, jti 

  • Refresh token’lar: 

  • Benzersiz jti içerir. 

  • fingerprint (IP, cihaz bilgisi) ile eşleştirilir. 

  • Revocation list ile sürekli kontrol edilir. 

  • Gereksiz claim’ler kaldırılmalı → JWT payload’ı minimal tutulmalı. 

Şekil 

9. CSRF Koruması 

  • SameSite=Strict cookie policy. 

  • Tüm state-changing isteklerde CSRF token zorunluluğu. 

  • CSRF token çerez ile değil, DOM’a gömülü hidden input olarak iletilmeli. 

  • Origin ve Referer header kontrolü aktif olmalı. 

Şekil 

10. Header ve Protokol Koruması 

hEADER 

AMAÇ 

Strict-Transport-Security 

HTTPS zorunluluğu 

Content-Security-Policy 

XSS ve inline script engeli 

X-Frame-Options 

Clickjacking önleme 

X-Content-Type-Options 

MIME-sniffing engelleme 

Referrer-Policy 

Gizlilik koruması 

Permissions-Policy 

Kamera, mikrofon erişim kısıtlaması 

 

Ek olarak: 

  • Rate limiting (örneğin IP başına 10 istek / dakika) 

  • Brute force koruması (örneğin 5 hatalı girişte lockout) 

  • CORS yapılandırması: Access-Control-Allow-Origin asla * olmamalı eğer Allow-Credentials=true ise. 

11. Test / Denetim Senaryoları 

  • XSS: UI tarafından token erişim testi. 

  • CSRF: CSRF token’sız istek testi. 

  • Refresh Reuse: Eski refresh token ile yenileme denemesi. 

  • Session Fixation: Aynı session ID farklı IP testleri. 

  • OTP: Şüpheli IP senaryosunda OTP isteği kontrolü. 

  • TTL Testleri: Redis session otomatik siliniyor mu? 

  • Cookie Güvenliği: HttpOnly, Secure, SameSite flag’leri aktif mi? 

Şekil 

 

12. Threat Modeling Tablosu 

Tehdit 

Önlem 

XSS 

HttpOnly cookie + CSP 

CSRF 

SameSite + CSRF token 

Token çalma 

Server-side session + AES şifreleme 

Refresh token reuse 

Rotasyon + revocation kontrolü 

Session hijacking 

IP + fingerprint bağlantısı 

Token replay 

jti + nonce + revocation list 

Brute force 

Rate limit + lockout mekanizması 

14. Uyumluluk (GDPR / KVKK) 

  • Session ID ve token’lar kişisel veri sayılabilir → AES şifreleme zorunludur. 

  • Loglar IP, zaman ve kullanıcı ID içerir; ancak anonim hale getirilmelidir. 

  • Çerez politikalarında amaç, saklama süresi ve kullanım açıklanmalıdır. 

  • Kullanıcı, talep ettiğinde tüm session verileri silinebilmelidir. 

Şekil 

15. Loglama ve Denetim 

  • Her login, refresh, logout olayı loglanmalıdır. 

  • Log formatı: {user_id, ip, user_agent, event_type, timestamp} 

  • PII veriler maskeleme uygulanarak saklanmalıdır. 

  • Log’lar WORM (Write Once Read Many) yapısında arşivlenmeli. 

  • SIEM (Security Information and Event Management) entegrasyonu önerilir. 

Şekil 

16. SSS (Sık Sorulan Sorular) 

S: Cookie kullanmak güvenli mi? 
C: Evet, HttpOnly + Secure + SameSite=Strict flag’leriyle kullanıldığı sürece XSS ve dinleme saldırılarına karşı güvenlidir. 

S: Neden token’lar client tarafında değil de server-side saklanıyor? 
C: LocalStorage gibi yapılar XSS’e açıktır. Server-side session store ise şifreli, yönetilebilir ve gerektiğinde iptal edilebilir. 

S: Refresh token sızarsa ne olur? 
C: Rotasyon sistemi sayesinde eski token anında geçersiz olur. Ayrıca fingerprint kontrolü ve IP farklılığı algılama sayesinde reuse tespit edilir. 

S: Bu mimari Zero Trust mı? 
C: Evet. Sunucular kimseye güvenmez, her istekte token doğrulama yapılır, minimum yetki uygulanır ve segmentasyon sağlanır.

 
 

 ADİL ALATAŞ

 

 

 

Bizi Takip Edin!