Blazor's natural separation from ASP.NET makes integration challenging. In the case of auth, things like authService.Challenge don't work.
In most cases, the result of a challenge is a redirection to a page (Identity, Cookies, OAuth) and in simple cases (Identity/Cookies) the user is able to setup the URL manually and redirect to it, but in other cases is not possible.
To better support these scenarios (and potentially have the equivalent of challenge in Blazor) we could extend authentication with the ability to start a challenge from the client/browser code by triggering a redirection to a well-known endpoint defined by the handler. In the case of cookies, the endpoint is just the /Account/Login endpoint. In the case of OAuth handlers, the endpoint they expose will in turn trigger ChallengeAsync(Scheme(s)) internally, set the state (nonce cookies, etc.) and proceed as normal from there.
The goal here would be to allow Blazor Server and WebAssembly apps to start a redirect via NavigationManager from interactive code without having to know the details about the handlers on the server (which server has access to, but webassembly doesn't) and trigger a full-page navigation to start the auth process).
It's a non-goal to avoid redirections on handlers that are request/response based, but instead give the users the ability to start the flow with a similar mechanism as in ASP.NET Core (ChallengeAsync) and to potentially persist state before the full-page navigation.
This would not change the fact that things like SignIn and SignOut wouldn't work from interactive methods as those require a request and response to be available, which it isn't in the Server case (and not in webassembly either since its running on the client).
mkArtakMSFT
commented
3 months ago
Blazor's natural separation from ASP.NET makes integration challenging. In the case of auth, things like
authService.Challengedon't work. In most cases, the result of a challenge is a redirection to a page (Identity, Cookies, OAuth) and in simple cases (Identity/Cookies) the user is able to setup the URL manually and redirect to it, but in other cases is not possible.To better support these scenarios (and potentially have the equivalent of challenge in Blazor) we could extend authentication with the ability to start a challenge from the client/browser code by triggering a redirection to a well-known endpoint defined by the handler. In the case of cookies, the endpoint is just the
/Account/Loginendpoint. In the case of OAuth handlers, the endpoint they expose will in turn triggerChallengeAsync(Scheme(s))internally, set the state (nonce cookies, etc.) and proceed as normal from there.The goal here would be to allow Blazor Server and WebAssembly apps to start a redirect via
NavigationManagerfrom interactive code without having to know the details about the handlers on the server (which server has access to, but webassembly doesn't) and trigger a full-page navigation to start the auth process).It's a non-goal to avoid redirections on handlers that are request/response based, but instead give the users the ability to start the flow with a similar mechanism as in ASP.NET Core
(ChallengeAsync)and to potentially persist state before the full-page navigation.This would not change the fact that things like SignIn and SignOut wouldn't work from interactive methods as those require a request and response to be available, which it isn't in the Server case (and not in webassembly either since its running on the client).