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.

5decision criteria

3packages compared

5pre-launch checks

The decision Shortlist Implementation plan Pitfalls & checklist When to revisit

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 & Trade-offs

Curated starting points to compare. Always evaluate suitability against your specific project requirements.

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.

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.

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
Document 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
Use 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
Store 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.

Risk

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.

Checklist

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.