ASP.NET Core'da JWT access ve refresh token: rotation, iptal ve kaçınılacak hatalar

Deneyimli bir ASP.NET Core geliştiricisi, üretimde kullandığı token akışını anlatıyor: 15 dakikalık imzalı JWT access token, veritabanında yalnızca SHA-256 özeti tutulan opak refresh token, her yenilemede rotation ve eski token yeniden görülürse tüm ailenin iptali. Yazı ayrıca .NET 10 / EF Core üzerinde sık yapılan yapılandırma hatalarını sıralıyor.

Kilit noktalar

• Access token 15 dakika, refresh token 7 gün; refresh değeri veritabanında sadece SHA-256 özeti olarak tutuluyor
• Her yenilemede rotation yapılıyor, eski satır ReplacedByTokenHash ile yenisine bağlanıyor
• İptal edilmiş refresh token tekrar sunulursa kullanıcının tüm aktif token'ları iptal ediliyor
• ClockSkew varsayılan 5 dakika yerine 30 saniyeye indirilmeli; 15 dakikalık token için bu önemli
• MapInboundClaims = false ayarlanmazsa User.FindFirst("sub") null döner
• Login ve refresh endpoint'lerine rate limiting, anahtara ise user-secrets / Key Vault ve ValidateOnStart

Akış iki farklı token türüne dayanıyor: her [Authorize] endpoint'inin kontrol ettiği, 15 dakika ömürlü ve state tutmayan imzalı bir JWT access token; bir de 7 gün geçerli, rastgele baytlardan üretilmiş opak bir refresh token. Refresh token asla JWT içine konmuyor ve sunucuda ham hâli değil, SHA-256 özeti unique index ile saklanıyor. Yaşam süreleri ve imzalama anahtarı başlangıçta doğrulanan tipli bir JwtOptions sınıfında tutuluyor; JwtBearer tarafında MapInboundClaims = false ve 30 saniyelik ClockSkew ayarlanıyor.

Yenileme endpoint'i rotation ve reuse detection uyguluyor: yeni token üretilirken eski satır iptal edilip ReplacedByTokenHash ile yenisine bağlanıyor; iptal edilmiş bir refresh token tekrar gelirse hırsızlık varsayımıyla kullanıcının tüm aktif token'ları geçersiz sayılıyor. Yazı ayrıca ham token saklamak, rotation ve reuse detection'ı atlamak, 5 dakikalık varsayılan ClockSkew'a güvenmek, MapInboundClaims'i açık bırakıp "sub" claim'ini bulamamak ve imzalama anahtarını git'e commit etmek gibi hatalara dikkat çekiyor. Zaman için TimeProvider kullanılması test edilebilirliği artırıyor.

Gerçek dünyada kullanımı

• Mobil uygulaması olan bir SaaS API'sinde cihaz yeniden başlasa da oturumun sürmesi gereken senaryolar
• Birden fazla cihazdan giriş yapılan bir müşteri portalında token hırsızlığı şüphesinde tüm oturumları kapatmak
• Refresh endpoint'i yoğun şekilde çağrılan bir API'de credential stuffing ve token denemelerine karşı rate limit koymak
• Mevcut bir ASP.NET Core Identity kurulumuna rotation ve reuse detection ekleyerek auth katmanını sertleştirmek

Neden önemli

Refresh token'ı ham saklamak veya rotation'ı atlamak, tek bir veritabanı sızıntısını ya da XSS'i kalıcı oturum hırsızlığına dönüştürür; bu kalıp, sızıntı sonrası hasarı sınırlayan en az kodla uygulanabilir yaklaşımı gösteriyor.

Benzer haberler

• ASP.NET Core'da rapor ve klasörlere rol tabanlı erişim: kullanıcılar, roller ve admin claim'leriDVDEV Community: #aspnetcore4 gün önce
• ASP.NET Core'da JWT access token üretmek ve doğrulamakDVDEV Community: #aspnetcore4 gün önce
• ASP.NET Core'da authentication ve authorization: ne zaman hangisi, güvenle nasıl yayına alınırDVDEV Community: #aspnetcore6 gün önce