Hızlı Özet (TL;DR)
JWT (JSON Web Token), durumsuz (stateless) kimlik doğrulama için endüstri standardıdır. Ancak JWT’lerin localStorage içinde saklanması, XSS zafiyetinde token’ın anında çalınmasına yol açar. Güvenli kurumsal mimari; kısa ömürlü (15 dakika) bir Access Token ve uzun ömürlü (7 gün) bir Refresh Token ikilisinden oluşur. Refresh Token istemciye yalnızca HttpOnly, Secure ve SameSite=Strict çerezleri üzerinden teslim edilmeli ve her kullanımda yenilenmelidir (Token Rotation).
Access Token ve Refresh Token Yaşam Döngüsü
Aşağıdaki tablo, kurumsal uygulamalarda uygulanan token hiyerarşisini özetlemektedir:
| Kriter | Access Token | Refresh Token |
|---|---|---|
| Kullanım Amacı | API uç noktalarına yetkili istek yapmak | Süresi dolan Access Token’ı yenilemek |
| Geçerlilik Süresi | 5 – 15 Dakika (Kısa ömürlü) | 7 – 30 Gün (Uzun ömürlü) |
| İstemcide Saklama Yeri | Bellekte (In-Memory / React/Vue State) | HttpOnly, Secure Cookie |
| Çalınma Riski | Çalınsa dahi 15 dakika içinde hükümsüz kalır | JavaScript tarafından okunamaz (XSS korumalı) |
| İptal Edilebilirlik | Durumsuz olduğu için anlık iptal zordur | Veritabanında/Redis’te tutularak tek tıkla iptal edilebilir |
Token Rotasyonu (Refresh Token Rotation) Nedir?
Bir kullanıcı yeni bir Access Token talep ettiğinde sunucu yalnızca yeni bir Access Token üretmekle kalmaz; mevcut Refresh Token’ı geçersiz kılarak yeni bir Refresh Token teslim eder:
- İstemci süresi dolmuş Access Token ile API’ye istek atar ve 401 Unauthorized alır.
- İstemci arka planda
POST /auth/refreshuç noktasına HttpOnly çereziyle istek gönderir. - Sunucu Refresh Token’ı doğrular, eski token’ı iptal eder ve hem yeni bir Access Token hem de yeni bir Refresh Token döner.
- Hırsızlık Koruması: Eğer eski bir Refresh Token tekrar kullanılmaya çalışılırsa sunucu hırsızlık şüphesiyle o kullanıcıya ait tüm aktif oturumları anında sonlandırır.
En Sık Yapılan 3 JWT Hatası
1. Hassas Verileri Payload İçine Koymak
JWT şifrelenmiş (encrypted) değil, yalnızca imzalanmış (signed) bir yapıdır. Base64 formatındaki payload herkes tarafından çözülebilir. Şifreler, TC kimlik numaraları veya kredi kartı verileri asla token içine yazılmamalıdır.
2. “none” Algoritmasına İzin Vermek
Sunucu tarafındaki JWT doğrulama kütüphanelerinde algoritma açıkça belirtilmelidir (algorithms: ['HS256']). Aksi takdirde saldırganlar header kısmını alg: "none" yaparak imzasız sahte token üretebilirler.
Güvenli, rol tabanlı yetkilendirmeye sahip modern web uygulamaları geliştirmek için Özel Yazılım Geliştirme ve Web Sayfası Tasarım hizmetlerimizden faydalanabilirsiniz.