ASP.NET Core'da authentication ve authorization: ne zaman hangisi, güvenle nasıl yayına alınır
ASP.NET Core'da authentication ve authorization'ı .NET 10 üzerinden uçtan uca anlatan kapsamlı bir rehber: hangi çağıran için hangi mekanizma, kaynak bazlı kontroller eksik kalınca veri nasıl sızıyor ve production öncesi neler doğrulanmalı.
Kilit noktalar
- Authentication bir ClaimsPrincipal üretir; erişime authorization karar verir, kimlik bilinmiyorsa 401, kimlik bilinip izin yoksa 403 döner.
- Seçimi çağırana göre yapın: server-rendered uygulamalar için cookie, SPA'lar için BFF + OIDC, API'ler için JWT Bearer, servisler arası için client credentials veya managed identity, iç yüksek güven için mTLS.
- En sık atlanan adım kaynak bazlı kontrol; URL'deki ID değiştirilerek başka bir kaydın okunması tam olarak buradan çıkar.
- Identity ürününüz değilse kendi token sunucunuzu yazmayın; IdentityServer4 bakımda değil, Entra ID, Keycloak, Duende veya OpenIddict tercih edin.
- Identity lockout, TOTP tabanlı 2FA ve .NET 10'dan itibaren passkey (WebAuthn/FIDO2) kaydı ile girişini kapsıyor.
- Issuer, audience, lifetime ve imza anahtarı doğrulamasını açık tutun, varsayılan beş dakikalık clock skew'ı daraltın; birden fazla instance'ta Data Protection key'lerini kalıcı hale getirin.
ASP.NET Core'un security altyapısı güçlü ama yanlış yapılandırılmaya açık; rehber .NET 10 için uçtan uca bir harita çiziyor. Başlangıç noktası tanıdık: her controller'da [Authorize] var, token'lar doğrulanıyor, ama URL'deki /invoices/1042 adresini /invoices/1043 yapan kullanıcı başka bir müşterinin faturasını görüyor. Authentication kim olduğunu söylemiş, kaydın sahibinin kim olduğunu ise kimse sormamış.
Rehberin geri kalanı bir seçim tablosu: server-rendered sayfalar için cookie, SPA'lar için BFF, API'ler için JWT Bearer, servisler için client credentials veya managed identity, yüksek güven gerektiren iç bağlantılar için mTLS ve kendi token sunucunuzu yazmak yerine harici bir identity provider. Identity lockout, TOTP ve .NET 10 ile passkey ekliyor; JWT doğrulamasında issuer, audience ve lifetime kontrolleri açık kalmalı, .NET 10'da ise cookie handler API endpoint'lerinde yönlendirme yerine 401/403 döndürüyor.
Gerçek dünyada kullanımı
- /invoices/{id} endpoint'lerinde yalnızca giriş yapılmış olmasını değil, kaydın o kiracıya ait olduğunu da doğrulaması gereken çok kiracılı bir SaaS.
- Önünde BFF bulunan ASP.NET Core API'si olan bir React SPA: tarayıcıya yalnızca HttpOnly cookie gider, token'lar sunucuda kalır.
- Ortak bir secret yerine client credentials veya managed identity ile iç API'ye bağlanan bir background worker ya da zamanlanmış job.
- Kendi user tablosunu bırakıp Microsoft Entra ID üzerinden cookie authentication ve OpenID Connect'e geçen bir kurum içi intranet uygulaması.
Neden önemli
ASP.NET Core uygulamalarında veri sızdıran erişim hataları çoğu zaman egzotik değil: eksik bir sahiplik kontrolü, kapatılmış bir token doğrulama bayrağı ya da 401 yerine yönlendirme yapan bir cookie. Rehber her birini tek tek işaret ediyor, böylece kendi servislerinizi denetleyebilirsiniz.