Open dazinator opened 5 months ago
This is a huge breaking change that's just not going to happen. At best you'd get an incompatible fork with no interop between them. Since you wouldn't be able to use any the HTTP based implementations in any other kind of app, what's the value in a shared abstraction? I'd expect there to be hardly any code left once you removed the HTTP specific parts, just a hollow shell.
2. Change the base implementations of
IAuthenticationService
andIAuthenticationHandlerProvider
(both are "scoped" services) to injectIHttpContextAccessor
and use HttpContext where needed.
IHttpContextAccessor
should be avoided whenever possible, there are too many ways to break it. Passing direct references is always preferred.
what's the value in a shared abstraction?
Having "one way" to do authentication irrespective of hosting model / paradigm. Sure the providers you'd pull in look different for a web app vs a non web app, but I see this as similar in nature to how the IServer
/ IHostLifetime
(from memory!) that is used for web app versus non web app is different but there is still the concept of a generic host - because I guess you want to standardise concepts more broadly across dotnet, so its less cognitive load for developers working across solutions.
Perhaps it comes down to whether you think Authentication
and Authorization
are first class concepts, worthy of addressing as such for dotnet more broadly, so there is a consistent story irrespective of the type of app. Or whether you think various eco systems in dotnet, should roll their own solutions.
Background and Motivation
I'd like to be able to sign in as a user, from a console app, similar to how I can from an aspnet core web app.
aspnet core offers a rich and extensible capability for configuring various authentication schemes, and handlers. However it currently couples itself in its implementation to
HttpContext
- where this coupling is not unnecessary.For example the journey begins when, to authenticate, we must get an
IAuthenticationService
- there are some convenience extension methods for HttpContext that resolve this for us fromHttpContext.RequestServices
and this is fine:This is not a problem because I can do the same from a console app with an
IServiceProvider
so no issue there.However looking at
IAuthenticationService.AuthenticateAsync()
(and similar api's) we can see that they pretty much all wantHttpContext
as an argument. This seems unnecessary coupling because any implementation ofAuthenticationService
including the default, can injectIHttpContextAccessor
and accessHttpContext
if it needs it that way. This is also true for anyIAuthenticationHandlerProvider
orIAuthenticationHandler
that is "web" specific.In other words, anything that needs http context has a way to get it, and there is no need to insist on this being passed all the way around the stack via the api's.
Conceptually, I propose the following, to allow
Microsoft.AspNetCore.Authentication
to be pushed into the runtime libraries asMicrosoft.Extensions.Authentication
with no dependency on HttpContext, and the the current HttpContext convenience authentication methods can remain in an aspnet core package, which is now a thin layer.HttpContext
arguments fromIAuthenticationService
IAuthenticationService
andIAuthenticationHandlerProvider
(both are "scoped" services) to injectIHttpContextAccessor
and use HttpContext where needed.IAuthenticationHandler
themselves like cookies based handlers etc or find away to adapt these to keep compatibility, whilst also allowing the larger goal of having handlers not dependent on HttpContext.Usage Examples
The end goal, is that once
Microsoft.Extensions.Authentication
exists you'd be able to share an authentication story for non web apps that looks a little like this:Alternative Designs
Risks
There would be breaking changes, but these might be minimised by adjusting base implementations to adapt current api's to conform to newer api's in some scenarios.