Authentication in connection and request pipelines

[SeanFeldman]

I've got a project that has authentication enabled. Authentication is working against IdentityService and is working great. Except I found an edge case when a context for authentication has an invalid state, which causes an exception to be thrown from a custom AuthenticationHandler<T>. That exception is then bubbled up, but is never handled in the custom ErrorHandlingMiddleware, registered before app.UseAuthentication() is called.

Upon further investigation, I've learned that authentication occurs in 2 places: the connection pipeline and the request pipeline. According to my understanding, the difference is that my error-handling middleware only wraps other middleware components added to the request pipeline, not the connection pipeline. Therefore, when an exception is thrown by the ASP.NET AuthenticationMiddleware (due to an error in the custom authentication handler), the error cannot be handled by the custom error middleware.

Is it possible to

1. Disable ASP.NET AuthenticationMiddleware for the connection pipeline, while keeping it for the request pipeline? or
2. Wrap ASP.NET AuthenticationMiddleware in a custom error-handling middleware?

[dmitry-pavlov]

Hey @SeanFeldman , try configuring error handling "global" way via app.UseExceptionHandler()

NOTE: of course, we could use custom middleware class but custom middleware comes into play after auth stuff. The standard app.UseExceptionHandler() is the first "built-in" middleware in the pipeline, so it will catch everything (icluding your auith issues).

See the middleware order here: https://docs.microsoft.com/aspnet/core/fundamentals/middleware#middleware-order-1

Also this post might put some light on options how you could handle errors https://code-maze.com/global-error-handling-aspnetcore/

Hope that helps!

[SeanFeldman]

TLDR: This is a combination of several things that went wrong and is unrelated to YARP.

If anyone reads past this point, in my case it was several things.

1. A custom nested deeper middleware was swallowing the exception
2. Custom middleware was registered to execute conditionally (UseWhen(...)), which seems to trigger authentication middleware more than once