Authentication Is Not a Security Architecture

Common Mistake Treating a valid JWT as proof that the request is safe. A JWT says something about issuance and validation. It says nothing about the route parameter the caller just incremented by one.

A valid token is a question, not an answer.

Security Belongs in the Architecture

Security in ASP.NET Core and .NET 9 applications is not a middleware. It is an architectural property designed across every layer of the system.

Design Decision In SecureStore, middleware may reject a request early, but it never approves access to a specific resource. That decision belongs to the domain layer.

Defense in Depth Without Theater

Good security is usually boring: each control limits the damage when another one fails.

Secure software assumes failure. It survives by making each failure smaller.

Trust Boundaries Are Design Objects

Trust is not a feeling. It is an architectural decision you can point to in code.

Security Review When I review a service, I draw the boundaries first and ask one question at each line: what stops being true here? If nobody on the team can answer for a given edge, that edge is where the next incident is already waiting.

Thinking Like an Attacker Changes the API

Attackers often exploit assumptions that were never enforced in code.

If I Were Reviewing This Pull Request I would not stop at RequireAuthorization(). I would ask where the tenant boundary is enforced, whether the query can ever return another tenant’s row, what gets audited on denial, and how the endpoint behaves when the token is valid but the resource belongs to someone else.

A Production JWT Configuration Is Narrow

In ASP.NET Core APIs, a JWT proves identity — not authorization. Production systems must combine JWT authentication with policy-based authorization and resource ownership validation.

using Microsoft.AspNetCore.Authentication.JwtBearer;
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
  .AddJwtBearer(options =>
  {
  options.MapInboundClaims = false; // keep claim names honest
  options.TokenValidationParameters = new()
  {
    ValidateIssuer = true,
    ValidIssuer = jwt.Issuer,
    ValidateAudience = true,
    ValidAudience = jwt.Audience,
    ValidateLifetime = true,
    ValidateIssuerSigningKey = true,
    RequireExpirationTime = true,
    RequireSignedTokens = true,
    ClockSkew = jwt.ClockSkew,
    NameClaimType = "sub",
    RoleClaimType = "roles"
  };
});

Production Tip Keep development shortcuts out of the authentication options. If local development needs a different authority, change configuration. Never teach production code to accept weak tokens, because that code outlives the developer who wrote it.

The Pipeline Should Read Like a Security Manifest

app.UseHsts();
app.UseHttpsRedirection();
app.UseSecurityHeaders();
app.UseRateLimiter();
app.UseAuthentication();
app.UseAuthorization();

Common Mistake Putting UseAuthorization() before UseAuthentication() is the easy mistake; the compiler practically catches it. The dangerous one is mapping an endpoint with no policy because the group looked protected somewhere else in the file.

Pipeline order is not a style choice. It is the sequence in which your assumptions are allowed to fail.

Authorization Is a Product Model, Not a Role Check

Design Decision Modeling permissions as operations changes how features are estimated. A new export feature is not a controller method plus a query. It is an authorization model: who can export, whether export reveals plaintext, whether support can initiate it, and which audit event is mandatory.

Resource Ownership Is Where Many APIs Fail

In a multi-tenant API, the most important line of code is the one that compares two tenant IDs.

protected override async Task HandleRequirementAsync(
  AuthorizationHandlerContext context,
  VaultItemOperationRequirement requirement,
  VaultItemAccessSnapshot resource)
{
  if (currentUser.TenantId != resource.TenantId)
    return; // wrong tenant: silent deny

  if (currentUser.UserId == resource.OwnerUserId)
  {
    context.Succeed(requirement); // owner
    return;
  }

  if (resource.AllowsTenantAdministrators &&
    context.User.HasClaim("permissions", requirement.Permission))
  {
    context.Succeed(requirement); // tenant admin with permission
    return;
  }
  if (await grantReader.HasGrantAsync(resource.Id, 
    currentUser.UserId, requirement.Permission))
  {
    context.Succeed(requirement); // explicit delegated grant
  }
}

Engineering Note The handler receives a resource snapshot, not an EF Core entity with half the database attached. Security checks should be explicit, cheap, and reviewable.

Endpoint Design Should Make Unsafe Paths Awkward

A safer endpoint design makes the insecure order of operations hard to write.

var access = await reader.GetAccessSnapshotAsync(id, ct);

if (access is null) 
  return TypedResults.NotFound();
var result = await authorization.AuthorizeAsync(
  httpContext.User, access, Policies.ReadVaultItem);
if (!result.Succeeded)
{
  await auditWriter.WriteDeniedAsync("vault_item.read.denied", id, ct);
  return TypedResults.NotFound(); // hide existence cross-tenant
}
var item = await reader.GetReadableItemAsync(id, ct); // sensitive read, last
await auditWriter.WriteSucceededAsync("vault_item.read.succeeded", id, ct);
return TypedResults.Ok(item);

If I Were Reviewing This Pull Request I would look for the order of operations first. If sensitive data is materialized before authorization runs, I would request a redesign even when the current endpoint happens not to return it. Today’s safe shortcut is tomorrow’s disclosure bug.

Secrets Are Not Configuration Values

Production Incident A team I worked with leaked a database password not through an attack, but through a debug log line that serialized the entire configuration object on startup. The fix was one line. The exposure window was four months. Secrets and configuration sharing the same object is how that happens.

Configuration describes behavior. Secrets grant power. Never store them as if they were the same thing.

if (builder.Environment.IsProduction())
{
  var vaultUri = builder.Configuration.GetValue<Uri>("KeyVault:Uri")!;
  builder.Configuration.AddAzureKeyVault(
    vaultUri, 
    new DefaultAzureCredential()
  );
}

Production Tip A production operator should be able to rotate a secret without rebuilding the API container. If rotation requires a new image, the secret is coupled to your delivery pipeline in the wrong place, and rotation will not happen during the incident when it matters most.

HTTPS, HSTS, and Headers Are Necessary but Not Sufficient

headers.TryAdd("X-Content-Type-Options", "nosniff");
headers.TryAdd("X-Frame-Options", "DENY");
headers.TryAdd("Referrer-Policy", "no-referrer");
headers.TryAdd("Cache-Control", "no-store");

Common Mistake Copying browser security headers from a frontend project into an API without understanding their effect. Headers should express the actual client and threat model, not whatever the last template included.

Rate Limiting Is a Fairness and Security Control

A poorly partitioned rate limiter can become an accidental denial-of-service against your own customers.

var partitionKey = tenantId is not null && subject is not null
  ? $"user:{tenantId}:{subject}" // fair per tenant + user
  : $"ip:{httpContext.Connection.RemoteIpAddress}";

Audit Logging Is Not Application Logging

Design Decision We chose the transactional outbox over fire-and-forget logging specifically so accountability survives a crash between “do the thing” and “record the thing.” That gap is small, but during an incident it is exactly the gap an investigator falls into.

If your audit trail can be lost during a process crash, it is not reliable enough for incident response.

var traceId = Activity.Current?.TraceId.ToString() ?? string.Empty;
return outbox.AddAsync(
  new AuditEvent(Guid.NewGuid(), now, tenantId, actorId,
    action, "VaultItem", resourceId, outcome, traceId),
  ct); // committed with the change

Engineering Note Do not lean on log retention policy to satisfy audit requirements. Logs are operational evidence with an expiry date. Audit events are business and security evidence with a chain of custody.

Monitoring Turns Security From Hope Into Feedback

Production Incident During one quiet weekend, denied-read metrics climbed slowly for a single subject across hundreds of resource IDs. No single request looked alarming. The aggregate did. Because the deny counter carried policy and endpoint dimensions, the on-call engineer found the enumeration in minutes instead of reading raw logs for hours.

You cannot defend what you cannot see, and you cannot see what you never instrumented.

Security Review Cloud primitives shift the location of risk; they do not delete it. Every time I move a control to the platform, I ask what new contract I just signed, and whether anyone on the team has actually read it.

A Production Checklist That Demands Evidence

Architecture Review This checklist belongs to engineering, not to compliance. The moment it becomes a spreadsheet detached from code and telemetry, it stops finding defects and starts producing signatures.

A checklist is not a substitute for thinking. It is insurance against forgetting on the day you are too tired to think.

Common Architectural Mistakes

Common Mistake Security reviews that focus only on middleware miss the domain entirely. The real exploit usually sails through middleware holding a perfectly valid token, and fails only if the domain model defends itself.

Most breaches are not clever. They are an ordinary request that no layer was responsible for refusing.

Where Security Actually Begins

Authentication is where API security begins. Architecture decides whether it survives production.

Frequently Asked Questions

Is JWT authentication enough to secure an ASP.NET Core API?

Why are ownership checks important in multi-tenant APIs?

What are the most common ASP.NET Core API security mistakes?

• Trusting JWT authentication alone
• Missing resource ownership validation
• Overusing administrator roles
• Weak JWT validation settings
• Storing secrets in configuration files
• Missing audit logging
• Insufficient monitoring and telemetry
• No rate limiting for public endpoints

📚 Modern .NET Engineering Series

➡️Part 2 — JWT Done Right: Common Mistakes Every ASP.NET Core Developer Makes