C# ASP.NET Core Authentication and Authorization

A bearer-token handler validates tokens according to its configured trust contract. Important checks include signature, issuer, audience and lifetime. Merely decoding a JWT's payload does not establish any of these facts. Never accept a caller's arbitrary header or query parameter as a verified user identity.

An API should obtain trusted issuer and audience settings from its configuration and use the supported handler. Real identity issuance belongs to an appropriate identity provider or authentication system, not a tutorial endpoint that manufactures tokens from any supplied username. Use HTTPS for credentials in transit and avoid logging the token. Claims are trustworthy only after the relevant authentication boundary validates their source and meaning.

A policy can require an authenticated user and specific claims or requirements. Apply it to the endpoint or endpoint group that needs protection. A permissive anonymous route should be an intentional exception, especially when the application uses a fallback policy. Adding authentication services alone does not automatically secure every route.

Claims describe facts under an issuer's contract. A claim named permission with value orders.read can be useful if the trusted issuer actually defines it. An OAuth scope claim often contains a space-separated list, so a simple exact-value requirement may not implement the intended scope semantics. Parse and evaluate that contract deliberately. A role is another authorization concept, but broad roles do not replace ownership checks on individual records.

For an actual minimal API, use a Web SDK project targeting net10.0 and reference Microsoft.AspNetCore.Authentication.JwtBearer version 10.0.0 or an appropriate supported compatible patch. The following complete Program.cs requires Auth:Authority and Auth:Audience settings for a real trusted provider. Missing settings fail clearly instead of enabling a permissive fallback.

using Microsoft.AspNetCore.Authentication.JwtBearer;

var builder = WebApplication.CreateBuilder(args);
string authority = builder.Configuration["Auth:Authority"]
    ?? throw new InvalidOperationException("Auth authority is required.");
string audience = builder.Configuration["Auth:Audience"]
    ?? throw new InvalidOperationException("Auth audience is required.");

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.Authority = authority;
        options.Audience = audience;
        options.RequireHttpsMetadata = true;
        options.MapInboundClaims = false;
    });
builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("ReadOrders", policy =>
        policy.RequireAuthenticatedUser()
              .RequireClaim("permission", "orders.read"));
});

var app = builder.Build();
app.UseAuthentication();
app.UseAuthorization();
app.MapGet("/orders", () => Results.Ok(new[] { "order-7" }))
    .RequireAuthorization("ReadOrders");
app.Run();

Without an acceptable bearer credential: HTTP 401.
With a valid authenticated token lacking orders.read: HTTP 403.
With a valid token satisfying ReadOrders: HTTP 200 and ["order-7"].

These outcomes depend on the configured issuer, its claim contract and valid credentials. They are not tokens supplied by the console fixture. The handler performs the authentication work; the endpoint applies the permission policy afterward.

An endpoint-level permission can allow access to the feature while a resource handler checks the particular order. Load the record under a safe query, identify its owner from trusted stored data, and compare it with a stable validated subject identifier. Do not accept an owner ID from the request body as evidence that the caller owns the record.

Decide whether a missing or unauthorized resource should return 404 or 403 under the application's disclosure policy. Both cases still require correct internal authorization. Keep the authorization and mutation within a coherent operation so a later change does not bypass the checked ownership assumption. Database constraints and concurrency rules can matter alongside the permission check.

Policy tests verify permissions under controlled principals. Authentication integration tests verify the configured handler's acceptance and rejection of credentials. Endpoint tests verify that protected routes actually apply their policy. Resource tests verify ownership, missing records and cross-user access. Each layer catches a different failure. Keep the protected-route inventory reviewable as endpoints are added, and verify that anonymous exceptions are intentional.

For cookie-based browser authentication, review CSRF protection for state-changing requests because browsers attach cookies automatically. Bearer APIs have different transport behavior but still need safe CORS and credential handling. Do not treat CORS as authorization. Keep logs limited to safe outcome and correlation fields, and never disable token validation merely to make a failing test pass.

• Microsoft: authentication
• Microsoft: configure jwt bearer authentication
• Microsoft: policies
• Microsoft: resourcebased