[Blazor][Wasm] Adds a library for performing autentication in blazor webassembly applications using OIDC

[javiercn]

This library includes the following components:

• AuthenticationManager: Is a component responsible for handling all the authentication operations.
• RemoteAuthenticationService: Handles the authentication details of the underlying protocol and provides information about the current user.
• IAccessTokenProvider: Handles the acquisition of access tokens used to authorize against resources by the app.

The general expected flow to follow by the templates is as follows:

• All authentication operations are handled by the AuthenticationManager inside a page that by default maps to
  '/authentication/{action}'.
• When a user is not authorized, it gets redirected to '/authentication/login' which sets up the appropriate state and redirects the user if necessary to the identity provider or successfully returns the user back to the authentication page if it was able to authenticate the user without requiring a redirect;
• When a redirection is needed, the user is sent bck to /authentication/login-callback where the authentication process is either completed successfully (and the user is redirected back to where he was originally) or the user is sent to /authentication/login-failed to indicate the reason of the authentication failure.

The authentication manager accepts multiple parameters to configure the UI that is displayed at each stage of the authentication process. Those steps are:

• Login
• Login callback
• Login failed
• Logout
• Logout callback
• Logout failed
• Logout succeeded

Authenticated users can request access tokens by injecting the IAccessTokenProvider service into their app and calling GetAccessToken().

By default, a token with the default scopes is provisioned, but additional tokens might be provisioned by passing options to the GetAccessToken method.

This method returns an AccessTokenResult object that indicates whether a token is available or a redirect operation is needed to acquire the token.

In that case, the user can preserve the state locally and navigate to the url in the result to start the token provisioning process, after which, it will be sent back to the current point.

There are a few more tests that I'm adding and low level implementation details that I'm handling, but it is ready for review.

[SteveSandersonMS]

Wow, this PR is epic!

Even though I have posted literally one million comments, I want to emphasise that I am totally in favour of this happening, and in general am really happy with the overall approach you're taking. I strongly support this work being done and am glad you're doing it!

[SteveSandersonMS]

Also in case it got lost in the flood of comments above, I want to ask again for any further work on this PR to be added as regular extra commits (non-squashed, non-force-pushed) so that follow-up review can just cover the subsequent diffs. It's taken about 4 hours to read through the first time 😄

[javiercn]

I've addressed things in individual commits. There are still things to address here that are listed here:

• Design
  • AccessTokenResultStatus
  • SignOutSessionStateManager
• Refactor
  • Enums for remote authentication actions
  • Enums for RemoteAuthenticationStatus
  • Get rid of GetCurrentUser
  • Cleanup GetCurrentUser
  • Cache GetCurrentUser results
  • Get the application paths in an agnostic way (Through a service?)
  • Look into removing GetStaticWebAssetManifest
• Bug fixes
  • Redirect to return url when user is not logged in.
    I'm refactoring the area, will handle that at part of that.
  • Cleanup navigate to register
    https://github.com/dotnet/aspnetcore/pull/18851/files#r376996189
    Deferred for now, I believe I hit some issues with Identity and decided to do it this wait. But I will re-evaluate it.
  • Caching on GetAuthenticationState
• Other
  • File issue for
    https://github.com/dotnet/aspnetcore/pull/18851/files#diff-b45fe29798979440f8a2fcda493077f6R7
  • File issue for -> Provide RedirectToLogin component in the app template.
    [Blazor] Provide redirect to login component in Microsoft.AspNetCore.Authorization #18979
  • EnableTypeScriptNuGetTarget -> Remove to avoid typescript SDK import errors.
    [Blazor][Wasm] Disable built-in typescript target #18980

I will go through the comments later today/tomorrow and resolve/answer comments as appropriate.

[javiercn]

I've updated the PR to address all the feedback, the only thing I haven't been able to do is the Enum switch as it breaks for some reason I can't tell (with a massive call stack), so I leave that as a follow-up.

[SteveSandersonMS]

Maybe this is also fixed in a later commit, but just in case it isn't:

Suggested change

	[Parameter] public RenderFragment LogingIn { get; set; } = DefaultLogInFragment;
	[Parameter] public RenderFragment LoggingIn { get; set; } = DefaultLogInFragment;

[SteveSandersonMS]

Suggested change

	[Parameter] public RenderFragment CompletingLogingIn { get; set; } = DefaultLogInCallbackFragment;
	[Parameter] public RenderFragment CompletingLoggingIn { get; set; } = DefaultLogInCallbackFragment;

[SteveSandersonMS]

Suggested change

	[Parameter] public RenderFragment LogOutSucceded { get; set; } = DefaultLoggedOutFragment;
	[Parameter] public RenderFragment LogOutSucceeded { get; set; } = DefaultLoggedOutFragment;

[SteveSandersonMS]

This is looking really good now.

One thing I'd like to check to complete my understanding: do we already have use cases for needing to inherit directly from RemoteAuthenticatorViewCore<T> elsewhere (e.g., for msal or something)? If we do then great, this all makes sense. If we don't yet have reasons to do that and the base class only exists for future extensibility, we should consider making the base class internal for now.

[SteveSandersonMS]

I like the 1-minute caching you've put in here. That feels like a good balance of efficiency and freshness.

Just so I can explain this to other people, can you summarise what it is that happens each time the 1-minute cache expires? What will we say in docs? Something like: The next time we evaluate authentication status, the system will make an HTTP request to the remote authentication service to verify that the user is still authenticated, and to update the list of claims associated with their ClaimsPrincipal. Is that accurate?

[SteveSandersonMS]

I think we have some naming issues here now. If I'm reading this correctly, the usage pattern would look like:

var accessTokenResult = await service.GetAccessToken(options);
if (accessTokenResult.TryGetAccessToken(out var accessToken))
{
    // ...
}

Issues:

1. GetAccessToken should have an Async suffix on its name, right?
2. It's confusing that both of the methods are basically called "get access token". If you got it the first time, why do you have to get it again?

I wish C# had a richer type system for this. The ideal result type would be AccessToken | AccessTokenRedirection. But since that's not an option, I'm tending to prefer the low-ceremony option you originally had, e.g.,

var result = await service.GetAccessTokenAsync(options);
if (result.Success)
{
    // ... use result.Token
}
else
{
    // ... use result.RedirectionUrl
}

If we're feeling fancy, we might even consider defining a deconstructor on AccessTokenResult so that in all the docs, we'd demonstrate its consumption like this:

var (token, redirectionUrl) = await service.GetAccessTokenAsync(options);
if (token != null)
{
    // ... use token
}
else
{
    // ... use redirectionUrl
}

However this relies on the idea that there will never be any other status besides "got token" and "needs redirection".

Let's discuss this later.

[SteveSandersonMS]

Maybe we could even rely on C#8 nullables to communicate the intent more clearly. If accessTokenResult.Token and accessTokenResult.RedirectionUrl were both marked as nullable, the compiler will force people to at least think about the possibility that the token isn't provided.

[SteveSandersonMS]

This is fantastic - great job @javiercn! Thanks for going through it with me in so much detail.

There are still a few typos in APIs to be resolved before merging - please see my suggested fixes (e.g., this one). I think all the typos are in members whose names contain LogingIn or Succeded.

Then, !