Authentication Handler as an Endpoint

[Kahbazi]

Now that almost everything (Controller, RazorPage, SignalR Hub, HealthCheck, Grpc) in ASP.NET Core is becoming an Endpoint, I'm curious is there a plan to make authentication handlers into endpoints?

[khellang]

It can't, as authentication needs to happen before the endpoint is executed. Endpoints are... endpoints, not middleware pipelines 😊

[Kahbazi]

I think I should have explain my point more. I'm not talking about the authentication process itself. I'm talking about the endpoints which I'm redirecting to from Identity Providers like /signin-microsoft or /signin-google . I believe these are endpoints which can be separated from authentication middleware.

[blowdart]

No there's not. Those aren't really endpoints, but ephemeral locations authentication intercepts, which, as Kristian points out needs to happen before normal endpoint code would execute.

What do you think would be gained by making them endpoints?

[Tratcher]

This is something I've briefly discussed with @rynowak. No, you couldn't convert all of an auth handler to endpoints, but moving some of the callbacks like /signin-microsoft to endpoints might be possible. That said, it would involve breaking up the auth handlers into several pieces and it's not clear what would be gained by doing so.

This part might scale better if you had a lot of auth handlers, routing is much more optimized for this scenario. The current code allocates every auth handler on every request (the schemes are singletons but the handlers are scoped).
https://github.com/aspnet/AspNetCore/blob/62351067ff4c1401556725b401478e648b66acdc/src/Security/Authentication/Core/src/AuthenticationMiddleware.cs#L42-L49

[brockallen]

+1 -- we discussed this somewhat already, but auth handlers are middleware for most requests, but endpoints for some specific requests (signouts and challenge callbacks). The signouts and challenge callbacks would benefit from being endpoints, I think -- mainly for the scale issue once you need 100+ OIDC/Ws-Fed/SAML handlers in your pipeline.

[Tratcher]

The transition might even be able to be done in a non-breaking way.

• Add a UseEndpoints option on the auth scheme options.
• The GetHandlerAsync allocation above would be skipped if UseEndpoints was enabled.
• something would give each scheme a chance to register endpoints if UseEndpoints were set.
• Since endpoints are largely stateless, they would probably allocate the handler when selected and call into their existing HandleRequestAsync logic.
• We'd have to ensure the dynamic add and remove scenarios still worked.

[khellang]

This also sounds semi-related to #6993?

[Tratcher]

@khellang distantly. Once you have endpoints then you can use them for url generation. However, most of the endpoint addresses in auth handlers are self-referential, generating them hasn't been much of an issue. The cookie auth urls called out in #6993 are more of an exception.

[Tratcher]

On a related perf note, this code even allocates handlers that don't implement IAuthenticationRequestHandler such as JwtBearer. We could probably add a scheme option to suppress that too.
https://github.com/aspnet/AspNetCore/blob/62351067ff4c1401556725b401478e648b66acdc/src/Security/Authentication/Core/src/AuthenticationMiddleware.cs#L42-L45

[Kahbazi]

you couldn't convert all of an auth handler to endpoints, but moving some of the callbacks like /signin-microsoft to endpoints might be possible.

Yes this was my intention. I should have specify better.
I would like to work on this if possible. Would you accept PR for this?

[Tratcher]

Would you accept PR for this?

Could you start by outlining a detailed design proposal? This has several moving parts that we need to make sure are accounted for before starting on a PR.

[analogrelay]

Triage: Seems reasonable, but definitely needs a bunch of design.