[Blazor] More auth fixes

[javiercn]

Follow up from #19966

Being able to customize the user during the authentication process as well as to control the flow of the authentication once the core authentication flow has a great importance when building applications using remote authentication protocols. It enables developers to:

• Enrich the user claims with data outside of the scope of the identity provider.
  • To add additional claims that might drive the UI.
  • To define roles for the user that are outside of those of the IdP.
• Collect additional information specific to the application that might be required for it to work.
• Prevent the authenticated user from accessing parts of the UI he's not allowed to.
  • (This is just an optimization of the UX, security must always be done server-side)

Goals/Decission drivers

• We want the authentication decissions to be centralized in one place within the UI, as this makes it easier to enforce the full authentication flow.
• We want the process of customizing the authenticated user simple, ideally it is done in one place.
• We want to separate the process of generating the authenticated user from the process of making authorization decissions.

Candidate solutions

• Do nothing and tell developers to override GetUserAsync on RemoteAuthenticationService.
• Include a callback in RemoteAuthenticatorViewCore to customize the user.
• Include a callback in RemoteAuthenticationOptions to customize the user.
• Define a new abstraction for generating the final authenticated user.

Define a new abstraction for generating the final authenticated user

I decided to implement a new abstraction to make it easier to customize the user being authenticated. This abstraction, UserFactory<RemoteUserAccount> handles mapping the user from the definition that the RemoteAuthenticationService provides into the ClaimsPrincipal that it is later on, used by the application.

Trade-offs

Adding a new primitive for mapping the user offers a single place where the mapping process can take place and allows developers to use normal extensibility mechanisms like dependency injection and so on in order to provision any service that they need to use to produce the final user.

It allows developers to focus on the mapping process without interfering with how or when the user is updated, which is a complicated process and can be handled by the framework.

It offers developers a natural place to implement caching strategies and other optimizations that might be required to implement the mapping process efficiently.

It introduces a new concept that users must understand, although this is not necessary until the user needs to be customized, given that a reasonable default implementation is provided.

It makes it complicated to inject some dependencies that make use of the IAccessTokenProvider since it is part of the RemoteAuthenticationService and injecting it would produce a cyclical dependency. This is mitigated in the default implementation by offering the IAccessTokenProvider as a property, which is supplied through an IAccessTokenProviderAccessor that delays the resolution until the property is first accessed. This makes sure that any custom implementation is encouraged to offer a suitable construction for dependency injection.

Finally, this option completely separates the mapping of the user from any other mechanic relate to the authentication process and enables decissions about the authentication flow to be taken at a later stage based on claims defined in the user, which gives developers the option to make those flows context sensitive.

Other options

Do nothing and tell developers to override GetUserAsync on RemoteAuthenticationService

In this option we would ask the users to override and customize RemoteAuthenticationService to produce the actual user and register their implementation in the dependency injection container.

Trade-offs

This option is cheap in terms of cost (free) but it offers a poor user experience and sets customers up for failure. The main reasons for this are:

• It is not easy to wire-up a RemoteAuthenticationService into the DI container as the same instance needs to be shared in different contexts. (AuthenticationStateProvider, IAccessTokenProvider, etc.).
• It forces users to re-implement all the caching logic that the RemoteAuthenticationService offers to cache the user, limiting the amount of JS interop calls that happen to check the user status.
• It establishes a tight contract between the RemoteAuthenticationService and the underlying AuthenticationService, which at the moment is just an implementation detail of the RemoteAuthenticationService.

Include a callback in RemoteAuthenticatorViewCore to customize the user

In this option we would define an event callback inside RemoteAuthenticatorViewCore that gets called when the user is authenticated.

Trade-offs

It would allow developers to write code in their Authentication.razor page that can access DI services in a way they are used to.

The main drawbacks for this approach are that RemoteAuthenticatorViewCore already handles many concerns and tacking an additional one to it just increases the complexity and makes it harder for users to understand it.

It forces that callback to be passed down through all the layers down to the RemoteAuthenticationService.

It can't be made to work as the mapping must be able to produce users even when a RemoteAuthenticatorViewCore is not part of the page.

Include a callback in RemoteAuthenticationOptions to customize the user

In this option we would include a callback in RemoteAuthenticationOptions that developers can set to customize the user.

Trade-offs

It is the best option for simple cases, since it makes it trivial to perform easy modifications. However, when more complex scenarios present themselves it sets up users for failure since it doesn't compose well, doesn't have a mechanism to resolve dependencies nor to hold on to other state for caching purposes and so on.

[SteveSandersonMS]

As with the comment about IAccessTokenProviderAccessor, I haven't spotted what this is used for. If you could clarify what consumes this feature that would be great.

[javiercn]

I answered here. The main goal is to make it easy to consume the IAccessTokenProvider from the UserFactory since that's a common thing and it's the lesser of evils.

[SteveSandersonMS]

Understood now - thanks

[javiercn]

🆙 📅

[SteveSandersonMS]

Excellent!