Skip to main content
N
About

Decision guide

Security packages for ASP.NET Core and .NET

Security package selection should begin with trust boundaries and threat model, not convenience. Decide where identities are issued, how tokens are validated, and which authorization model maps to your service architecture and compliance obligations.

5 criteria3 packages5-point checklist

The decision to make

Which security package set should a .NET application use for authentication and authorization?

  • Identity provider model: first-party identity, Entra ID, B2C, external OIDC or mixed enterprise federation.
  • Token format and validation requirements for APIs, web apps and background workers.
  • Authorization needs: role-based, policy-based and resource-based checks.
  • Operational controls for key rotation, secret handling, audit logging and incident response.
  • Licensing and support posture for identity server components.

Shortlist and trade-offs

These options are starting points, not an exhaustive market list. Verify the current release, compatibility, license and advisory information for your project on the linked package pages.

1

Microsoft.Identity.Web

High-level integration package for ASP.NET Core apps and APIs using Microsoft identity platforms.

Inspect package
Best fit
Organizations standardizing on Entra ID flows for web apps, APIs and delegated token acquisition.
Validate first
Primarily optimized for Microsoft identity ecosystems rather than provider-neutral federation scenarios.
2

Microsoft.AspNetCore.Authentication.JwtBearer

JWT bearer authentication middleware for validating access tokens in ASP.NET Core APIs.

Inspect package
Best fit
Resource APIs that need standards-based token validation and policy-driven authorization.
Validate first
You still need robust issuer configuration, key rollover handling and defense-in-depth authorization rules.
3

Duende.IdentityServer

OpenID Connect and OAuth 2.0 server framework for issuing tokens and centralizing identity workflows.

Inspect package
Best fit
Organizations that require a self-operated identity provider with custom protocol and consent flows.
Validate first
Commercial licensing and operational identity expertise are required for long-term ownership.

Practical implementation plan

  1. 1Document trust boundaries, assets, actors, token issuers, and authorization decisions before selecting packages. Convert the threat model into explicit authentication, authorization, audit, and incident-response requirements.
  2. 2Use platform middleware to validate issuer, audience, signing keys, lifetime, and algorithms. Enforce authorization with named policies close to the protected resource, including resource ownership checks where needed.
  3. 3Store secrets in managed secret stores, rotate them, and test key rollover. Add security events and alerting for failed authentication, privilege changes, and sensitive actions without logging credentials or tokens.

Common pitfalls

  • Validating a JWT signature while skipping issuer, audience, lifetime, or algorithm validation.
  • Using roles alone for tenant or resource ownership decisions when the user is authenticated but not entitled to that specific record.
  • Placing connection strings, client secrets, or signing keys in source control, environment dumps, or diagnostic logs.

Before production

  • Authentication validates issuer, audience, lifetime, algorithms, and signing-key rotation.
  • Authorization policies enforce tenant and resource ownership, not only UI visibility.
  • Secrets are managed, rotated, and absent from repositories, logs, and error responses.
  • HTTPS, secure headers, CORS, rate limits, and request-size controls match the API threat model.
  • Security logs are auditable, access-controlled, and connected to an incident response process.

When to revisit this choice

Revisit security package choices when threat models change, zero-trust requirements expand, or compliance frameworks require stronger identity controls.

Data, method and limits

Sources: the public NuGet v3 registry and NuBrowse editorial review. Refresh: package pages read current registry metadata when viewed; guide text is revised separately. Method: the shortlist favours distinct use cases and spells out trade-offs instead of calculating a quality score. Limit: validate the specific version, license, framework and operational requirements in your project.