🔐 Authentication & Authorization in .NET — Various Approaches

1️⃣ Authentication Methods

1. Cookie-based Authentication (Forms Auth)

• How it works: User logs in → server sets an encrypted authentication cookie → browser sends cookie on each request.
• Where used: Traditional web apps (MVC, Razor Pages).
• Built-in support: services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme) + app.UseAuthentication().
• Pros: Works well for server-rendered apps.
• Cons: Not great for APIs; needs CSRF protection.

---

2. JWT Bearer Authentication

• How it works: User logs in → server issues JWT token → client sends Authorization: Bearer <token> on each request.
• Where used: Web APIs, mobile apps, SPAs.
• Built-in support: AddJwtBearer().
• Pros: Stateless, cross-platform.
• Cons: Revocation is tricky; must handle refresh tokens.

---

3. ASP.NET Core Identity

• How it works: Full-fledged membership system for handling users, passwords, roles, claims, 2FA, etc.
• Where used: Web apps, APIs requiring user management.
• Pros: Provides login, registration, password hashing, security stamp, token providers.
• Cons: Can be heavy if you need only simple auth.

---

4. OAuth2 / OpenID Connect (OIDC)

• How it works: Delegates authentication to external providers (Google, Microsoft, Facebook, GitHub, Azure AD, etc.).
• Where used: Enterprise apps, apps needing social logins.
• Libraries: AddAuthentication().AddOpenIdConnect().
• Pros: Offloads auth to trusted providers. Supports single sign-on (SSO).
• Cons: More setup; requires secure token validation.

---

5. API Key Authentication

• How it works: Client sends a static API key in header or query string. Server validates key.
• Where used: Service-to-service communication, internal APIs.
• Pros: Simple, easy for machines.
• Cons: No user identity, just client identity; must protect keys.

---

6. Certificate Authentication (Mutual TLS)

• How it works: Client presents X.509 certificate; server validates against trusted CA.
• Where used: High-security service-to-service APIs.
• Pros: Very strong; no password/token exchange.
• Cons: Certificate management complexity.

---

7. Windows Authentication / Integrated Security

• How it works: Uses Active Directory credentials; relies on Windows domain.
• Where used: Intranet apps in corporate environments.
• Pros: Seamless for internal users.
• Cons: Limited to Windows/AD environment.

---

8. External Identity Providers (Social logins)

• Examples: Google, Microsoft, Facebook, GitHub.
• Setup: services.AddAuthentication().AddGoogle()/AddFacebook()/AddMicrosoftAccount().
• When to use: Consumer-facing apps requiring social login.

---

2️⃣ Authorization Approaches

1. Role-based Authorization

• How it works: Assign roles (Admin, User, Manager) to users.
• Usage:

  [Authorize(Roles = "Admin")]
  public IActionResult AdminOnly() { ... }
  

• Pros: Simple and common.
• Cons: Coarse-grained; not flexible for complex permissions.

---

2. Claims-based Authorization

• How it works: Users have claims (email, department, permission). Policies check these claims.
• Usage:

  services.AddAuthorization(options =>
  {
      options.AddPolicy("HROnly", policy => policy.RequireClaim("department", "HR"));
  });
  
  [Authorize(Policy = "HROnly")]
  public IActionResult HRPage() { ... }
  

• Pros: Fine-grained, flexible.
• Cons: More setup.

---

3. Policy-based Authorization

• How it works: Define reusable authorization policies using requirements + handlers.
• Usage:

  services.AddAuthorization(options =>
  {
      options.AddPolicy("Over18", policy => policy.Requirements.Add(new MinimumAgeRequirement(18)));
  });
  

• Pros: Encapsulates logic, testable.
• Cons: Slightly more complex than roles/claims.

---

4. Resource-based Authorization

• How it works: Authorization based on specific resource instance, not just role/claim.
• Example: Only the owner of a document can edit it.
• Usage: IAuthorizationService.AuthorizeAsync(user, resource, requirement).
• Pros: Per-object permissions.
• Cons: Requires custom code for each resource type.

---

5. Custom Authorization Handlers

• How it works: Implement IAuthorizationHandler to enforce complex logic (e.g., check database values).
• Usage:

  public class MinimumAgeHandler : AuthorizationHandler<MinimumAgeRequirement>
  {
      protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, MinimumAgeRequirement requirement)
      {
          var dob = context.User.FindFirst(c => c.Type == ClaimTypes.DateOfBirth)?.Value;
          if (dob != null && DateTime.Parse(dob).AddYears(requirement.MinimumAge) <= DateTime.Today)
              context.Succeed(requirement);
          return Task.CompletedTask;
      }
  }
  

• Pros: Ultimate flexibility.
• Cons: More code to maintain.

---

3️⃣ Mix & Match Scenarios

• API with JWT + Role-based auth → Most common for modern REST APIs.
• Web app with Cookie + Claims-based auth → Good for intranet or server-rendered apps.
• Enterprise app with OIDC (Azure AD) + Policy-based auth → Standard in corporate environments.
• Microservices with API Keys or Certificates → Service-to-service communication.

---

✅ Summary Table

Authentication Method	Use Case	Built-in Support	Common Authorization Style
Cookie Auth	MVC / Razor Pages	✅	Roles, Claims
JWT Bearer	APIs / SPAs / Mobile	✅	Roles, Claims, Policies
Identity	Full user management	✅	Roles, Claims
OAuth2 / OIDC	Social login / SSO	✅	Claims, Policies
API Key	Service-to-service	⚠️ (custom middleware)	N/A
Certificate	High-security APIs	✅	Custom
Windows Auth	Intranet (AD)	✅	Roles
External IdP	Google, Facebook, etc.	✅	Claims

---

⚡ Best Practice Recommendation:

• For APIs: Use JWT (short-lived access tokens + refresh tokens) with policy-based authorization.
• For web apps: Use Cookie Auth + ASP.NET Identity.
• For enterprise: Use OpenID Connect / Azure AD with claims/policies.
• For services: Use API Keys or Mutual TLS.