Authentication vs Authorization

Two questions get asked on nearly every request your application handles. Who is this? And are they allowed to do the thing they are asking for?

Authentication answers the first. Authorization answers the second. They run at different moments, fail in different ways, and belong in different parts of your code. Treating them as one step is behind a large share of access control bugs, because a system that knows who you are will happily let you do anything unless something separate says otherwise.

This lesson assumes you have used a login form and can read a small amount of C#. Everything else is defined as it appears.

var builder = WebApplication.CreateBuilder(args);

// 1. Authentication: how a request's identity gets established.
builder.Services
    .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer();

// 2. Authorization: what an established identity is allowed to do.
builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("CanApproveOrders", policy =>
        policy.RequireAuthenticatedUser()
              .RequireRole("OrdersManager"));

    // Closed by default. An endpoint with no requirements of its own
    // still needs an authenticated user, unless it says [AllowAnonymous].
    options.FallbackPolicy = new AuthorizationPolicyBuilder()
        .RequireAuthenticatedUser()
        .Build();
});

var app = builder.Build();

app.UseAuthentication();   // works out who you are
app.UseAuthorization();    // decides whether you may proceed

app.MapGet("/orders/{id:int}", GetOrder);

app.MapPost("/orders/{id:int}/approve", ApproveOrder)
   .RequireAuthorization("CanApproveOrders");

app.Run();

• The two registrations are deliberately separate. Replacing tokens with cookies later changes the first block and leaves the second untouched, because the policy talks about a role rather than about how the role was proved.
• UseAuthentication runs before UseAuthorization, and the order is not cosmetic. The authorization step has nothing to decide with until the principal exists.
• FallbackPolicy applies to any endpoint that states no requirements of its own. It flips the default from open to closed, so a forgotten attribute produces a refusal rather than an unprotected endpoint. Making the safe case the lazy case is worth more than any amount of care.
• RequireAuthorization names the policy for the approve endpoint. The handler itself does not repeat the role check, which keeps one rule in one place.

Authorization is a per-request decision, and that is the part most often got wrong. Checking permissions once at login and remembering the answer is tempting, because it looks like a saving. It fails for two reasons.

The first is that the answer changes. An employee moves team, a role is revoked, an account is disabled. A decision cached for the life of a session keeps working after the permission behind it has gone.

The second is more fundamental: the decision depends on the operation, and often on the specific record. A session that may read its own orders is not a session that may read every order. A check that ran at login, before any order was named, cannot know which order is about to be loaded. It was never in a position to answer the question.

The front end hiding a button is not a check either. It is a courtesy to the user. Your endpoint is reachable without your front end, by anything that can make an HTTP request, and it has to refuse on its own.

private static async Task<IResult> GetOrder(
    int id,
    ClaimsPrincipal user,
    OrdersDbContext db,
    CancellationToken ct)
{
    var order = await db.Orders
        .AsNoTracking()
        .FirstOrDefaultAsync(o => o.Id == id, ct);

    if (order is null)
    {
        return Results.NotFound();
    }

    var employeeId = user.FindFirst("employee_id")?.Value;

    var isOwner = order.PlacedByEmployeeId.ToString() == employeeId;
    var isManager = user.IsInRole("OrdersManager");

    if (!isOwner && !isManager)
    {
        // 403: we know who you are. The answer is no.
        return Results.Forbid();
    }

    return Results.Ok(OrderResponse.From(order));
}

• The fallback policy already guaranteed an authenticated user before this method ran. That gave us a name, not a decision about this order.
• The ownership rule needs the record, so it cannot run in middleware. The check sits next to the data it depends on. ASP.NET Core calls this resource-based authorization, and IAuthorizationService lets you move the rule into a reusable handler once more than one endpoint needs it.
• Results.Forbid produces 403. Results.Challenge produces 401. Returning 401 here would tell a signed-in employee to sign in again, which is misleading advice and hides a permission problem behind a login screen.
• Reading the employee id from the principal, not from the request, is the whole point of the claim. An id supplied by the caller is a statement by the caller about itself.
• One trade-off to decide deliberately: returning NotFound before the permission check tells a caller which order ids exist. Inside one company that is usually acceptable. Where it is not, return NotFound for refusals too, and accept that debugging gets harder.