Middleware Order

In the pipeline, order is not a matter of style. It is the behaviour of the application. The same six lines in a different sequence give you a different API, and the difference usually surfaces either as an error that makes no sense or as a security hole that makes no noise at all.

One rule explains every specific case: a component can only act on information that already exists. Authorization cannot check permissions before authentication has established who is asking. Nothing can read an endpoint's metadata before routing has selected an endpoint. Exception handling can only catch what happens after it.

This lesson is the one to come back to. Most confusing behaviour in an ASP.NET Core application is an ordering problem wearing a disguise.

var app = builder.Build();

app.UseExceptionHandler("/error");   // outermost, so it wraps everything below
app.UseHttpsRedirection();
app.UseStaticFiles();                // public assets, no credential needed
app.UseRouting();                    // decides which endpoint this request is for
app.UseCors("directory-clients");
app.UseAuthentication();             // who is calling?
app.UseAuthorization();              // are they allowed to do this?
app.MapControllers();

app.Run();

• UseExceptionHandler goes first because it is a try and catch around everything registered after it. Anything above it is outside the net.
• HTTPS redirection comes early, so a request that is about to be redirected does not have work done on it first.
• Static files sit before authentication deliberately. These files are public, and serving them without running authentication saves that work on every image, stylesheet and script.
• UseRouting selects the endpoint and records it on the context. Every component that needs to know which endpoint was matched has to be registered after this line.
• CORS runs after routing so it can read the policy attached to the chosen endpoint, and before authentication so that a rejected request still carries CORS headers on the way back.
• Authentication, then authorization, in that order, always. The first populates the user on the context; the second inspects it and the endpoint's requirements.
• MapControllers is last so the file reads in the order the pipeline runs. Endpoint execution is appended to the end of the pipeline regardless of where the Map call appears, which is a detail worth knowing and not worth relying on.

var app = builder.Build();

app.UseAuthorization();              // fault 1: nothing has identified the caller yet
app.UseAuthentication();
app.UseRouting();                    // fault 2: the security middleware ran before this
app.UseCors("directory-clients");    // fault 3: after the middleware that can reject
app.UseExceptionHandler("/error");   // fault 4: wraps almost nothing
app.MapControllers();

app.Run();

• Nothing here fails to compile, and the application starts cleanly. Every fault is a behaviour, discovered later by somebody debugging a symptom.
• Two of these faults lock valid callers out, which you will hear about quickly. One of them lets callers through, which you may not hear about at all.