[Blazor server] On demand principal revalidation

[javiercn]

Summary

Blazor server apps authenticate the user at the beginning of the circuit lifetime and offer a mechanism for updating the principal when used in conjunction with identity. The way Blazor Server handles authentication is confusing for some users since they are used to the authentication to be re-validated on every request/response, as opposed to Blazor, for which the authentication by default lasts the entire lifetime of the circuit.

Motivation and goals

• This aspect of Blazor server authentication is a common point of confusion we receive frequent feedback about.
• There are plenty of issues on our GH repo about this problem.

In scope

Provide a mechanism that lets the server initiate a request for re-validating the user credentials and updating the Principal accordingly.

The general idea is to provide an endpoint that receives a protected payload TBD, authenticates the user and returns a protected payload with the updated authentication context that the server can validate and use to update the Principal before the next authorization check.

Out of scope

Re-validating authentication is limited to authenticating the user against the schemes defined by a policy, there is no way to customize this process besides that.

Risks / unknowns

This is a security related feature, so it needs to be thread model analysis.

Examples

@attribute [RevalidateAuthentication]

The authorizerouteview would check this attribute on the handler and act accordingly.

There would also be an imperative API that can be used from event handlers to check this.

await AuthStateProvider.RevalidateAuthentication()`

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[danroth27]

Dependent on #5297

[danroth27]

The SignalR folks are planning to start investigating #5297 in the .NET 10 timeframe, but we don't expect this to land for .NET 10.