Authentication revalidation for server-side Blazor

[mkArtakMSFT]

No description provided.

[mkArtakMSFT]

Moving the client-side work out to: #10846

[SteveSandersonMS]

Done in #11548

[Yen]

Please let me know if I am wrong, but #11548 does not solve this issue for authentication, it solves it for identity based authorization.

We are currently using cookie authentication with microsoft AD to validate logins to internal applications where we do not require associated data from a db with identity. For the traditional MVC style system we would set CookieAuthenticationOptions.ExpireTimeSpan and be done with it, but how would we go about expiring a server side blazor session in a secure way outside of rolling our own hacks?

What we are currently using is a check in OnGet to see if the user is authenticated followed by a redirect to a login razor page from the _Host.cshtml file. This is fine for stopping people from loading any of the blazor pages using _Host as the root, but does nothing to stop an existing connection from being used.

Is there any way this system can be used with authentication without identity as we do not want an entity framework store of any sort where not required, and if not, are there plans to have this scenario supported?

[ADefWebserver]

@Yen Take a look at: A Demonstration of Simple Server-side Blazor Cookie Authentication

[Yen]

@ADefWebserver Thank you for your reference but I don't believe this is what I am looking for. I am sure it is possible to check for the authentication state by manually looking at the expiration dates of the cookies as they are given during the creation of the websocket instance. However this is not a complete solution, nor do I believe it is a response to this issue. In this case we are looking for a way to revalidate authentication on the existing websocket connection, without the requirement to validate each function call made from the blazor component.

[SteveSandersonMS]

@Yen You're correct that the built-in system only addresses the scenario for identity-based authentication. It periodically checks whether the user's security stamp has changed, and if so, invalidates their current authentication state (which in turn causes authorization rules to be re-evaluated).

We don't have, and aren't planning to have in 3.0, and general system for reauthenticating across all possible authentication types. The reason is that there isn't a general way to do it. For example, we don't have a way of asking the cookie authentication system to re-check the possible expiry of tokens encoded into a cookie.

For now, if this is required in your app, consider implementing a custom AuthenticationStateProvider that uses whatever logic you want to recheck authentication state, similar to how we did it for identity.

Longer term we hope to add a more general feature to SignalR to enable rechecking of authentication state, but it won't be in 3.0. cc @anurse

[Yen]

@SteveSandersonMS Thanks for the response Steve, it is a shame that your support for this is limited to those using Identity but understandable.

I wanted to add, for anyone else having the same issue, that to solve my issue I have decided to make a custom AuthenticationStateProvider that uses HttpContext.AuthenticateAsync with the cookie authentication scheme to get an AuthenticateResult. This then gives me access to IssuedUtc and ExpiresUtc, which is all the information needed to perform the check and invalidate the connection. (In my case I am ignoring the ExpiresUtc and using the current CookieAuthenticationOptions.ExpireTimeSpan for the calculation so that changes in the expiration duration cross session is considered.)

I don't know if this is enough to classify for your "we don't have a way of asking the cookie authentication system to re-check the possible expiry of tokens encoded into a cookie.", or if you are looking for something else I have missed. :)