ASP.NET Core'da JWT access token üretmek ve doğrulamak

Bu rehber, ASP.NET Core Identity kullanıcıları için JsonWebTokenHandler ile imzalı 15 dakikalık access token üretmeyi ve JwtBearer tarafında bu token'ların issuer, audience, ömür ve imza kontrollerini sıkı biçimde yapmayı anlatıyor. Yazı, gerçek projelerde sık karşılaşılan claim mapping, API'de AddIdentity kullanımı ve middleware sırası hatalarına da dikkat çekiyor.

Kilit noktalar

• Token üretimi ve doğrulaması aynı JsonWebTokenHandler üzerinden yapılıyor; .NET 8'den beri JwtBearer varsayılan olarak bu handler'ı kullanıyor
• HS256 en az 32 byte anahtar ister; daha kısa anahtar IDX10720 hatasıyla token oluşturmada patlar, bu yüzden uzunluk açılışta kontrol edilmeli
• Access token ömrü 15 dakika, doğrulamada 30 saniyelik clock skew tanımlanıyor; issuer, audience ve lifetime sıkı kontrol ediliyor
• JWT imzalıdır ama şifreli değildir: payload'daki claim'ler okunabilir, hassas veri konmamalı
• sub claim'inin okunabilmesi için claim type mapping kapatılmalı; aksi halde ICurrentUser.UserId boş döner
• IdentityDbContext<AppUser> içinde base.OnModelCreating(builder) çağrılmazsa EF Core primary key hatası verir

Yazı, Angular ve mobil istemcilerin aynı Store.Api'yi çağırdığı bir senaryodan yola çıkıp ASP.NET Core Identity ile kullanıcı kaydı, giriş ve endpoint korumasını uçtan uca kuruyor. Token üretimi, .NET 8'den beri JwtBearer'ın da doğrulamada kullandığı JsonWebTokenHandler ile yapılıyor; böylece aynı handler iki tarafta da çalışıyor. İmzalama anahtarı HS256 için en az 32 byte gerektirdiğinden, rehber anahtar uzunluğunu uygulama açılışında kontrol etmeyi ve anahtarı user secrets ya da ortam değişkeninde tutmayı öneriyor.

Token içeriğinde sub, email, role ve jti claim'leri taşınıyor, ömür 15 dakika ve doğrulamada 30 saniyelik clock skew kabul ediliyor. Dikkat çeken nokta, imzalanmış bir JWT'nin şifreli olmaması: payload'ı herkes okuyabilir, bu yüzden claim'lere hassas veri konmamalı. Servis katmanının HttpContext'e bağımlı olmaması için ICurrentUser soyutlaması ekleniyor; ancak sub claim'inin okunabilmesi için claim type mapping'in kapatılması gerektiği vurgulanıyor.

Gerçek dünyada kullanımı

• Hem web hem mobil istemcisinin aynı API'yi çağırdığı ve cookie yerine Bearer token gereken çoklu istemci senaryoları
• Sipariş, denetim kaydı gibi servislerin HttpContext'e bağımlı olmadan kullanıcı kimliğine erişmesi gereken katmanlı uygulamalar
• Token süresini FakeTimeProvider ile test etmek isteyen, TimeProvider üzerinden zaman okuma yapan kimlik doğrulama servisleri
• Hatalı parola denemelerini sayıp 5 denemeden sonra hesabı 15 dakika kilitleyen giriş akışına ihtiyaç duyan API'ler

Neden önemli

Kimlik doğrulamayı ilk kez kuran ekiplerin en sık yaptığı hataları (claim mapping, yanlış middleware sırası, kısa imza anahtarı) tek bir rehberde topluyor; bu hatalar üretimde 401 ve güvenlik açıkları olarak geri dönüyor.

Benzer haberler

• ASP.NET Core'da authentication ve authorization: ne zaman hangisi, güvenle nasıl yayına alınırDVDEV Community: #aspnetcore3 gün önce
• ASP.NET Core'da rapor ve klasörlere rol tabanlı erişim: kullanıcılar, roller ve admin claim'leriDVDEV Community: #aspnetcore1 gün önce
• Telr ödemeleri ASP.NET Core'da: dokümanların atladığı kısımlarDVDEV Community: #aspnetcore1 gün önce