Aspnetcore: implement a self-override of AuthenticationStateProvider bug in server-side-blazor

[aiqoo]

First I'm sorry about my written English
I've had a recurring problem and I hope you can help me

I am trying to implement a self-override solution for uthenticationStateProvider without EF.

I used two project examples as a base, both written in CSB.
I went through them step by step and implemented them as a SSB project
the first is chris sainty ex:
Link: https://chrissainty.com/securing-your-blazor-apps-authentication-with-clientside-blazor-using-webapi-aspnet-core-identity/

the second is Steve Sanderson "MissionControl" demo:
Link: https://github.com/SteveSandersonMS/presentation-2019-06-NDCOslo/tree/master/demos/MissionControl

Both of them I managed to implement and run in the SSB environment with minor changes depending on the environment

Describe the bug

In Both of them The AuthenticationState does not change when user signin, the same code in CSB mode does change the AuthenticationState.

JWT is created and saved inlocal storage but the AuthenticationState does not change accordingly and I still remain in unauthorized state

[mkArtakMSFT]

Hi. It looks like this is a question about how to use ASP.NET Core. While we do our best to look through all the issues filed here, to get a faster response we suggest posting your questions to StackOverflow using the asp.net-core-blazor tag.

[enetstudio]

@mkArtakMSFT, blazor tag, not asp.net-core-mvc tag.

[enetstudio]

As suggested by @mkArtakMSFT, you'd better post your questions in StackOverflow using the blazor tag, accompanied by a repo of your apps, so we can detect the issues you're facing.

However, it is a bad idea to use Jwt with server-side Blazor. Why validate the user on the server, a very secure environment, and then send a Jwt token to be stored on the user's localStorage. Do you see the absurd ? Still worse, this may introduce security vulnerabilities and risks that you wouldn't want to undergo.

The following is what SteveAnderson has to say about implementing a custom AuthenticationStateProvider in server-side Blazor, which I guess, you did:

For server-side Blazor, it is very unlikely that you should implement a custom AuthenticationStateProvider. The built-in implementation already integrates with ASP.NET Core's built-in authentication mechanisms. If you implement a custom one, you may introduce security vulnerabilities.

The only common scenario for a custom AuthenticationStateProvider is client-side Blazor, because in that case you may want to integrate with any number of external authentication systems independently of your server-side code. Also, in client-side Blazor, authentication only exists to present a convenient UI to well-behaved users - it's not actually the place where security is enforced, since client-side rules can always be bypassed.

Without seeing your code I can't say much except to mention these:

• Known issue: In ASP.NET Core 3.0 Preview 6, it's not possible to specify custom NotAuthorizedContent or AuthorizingContent on the Router component with server-side Blazor (though it does work with client-side Blazor). This will be fixed in the Preview 7 release

• As far as I remember (not completely sure), the AuthenticationStateProvider in server-side Blazor remains unchanged during the lifetime of the connection, which implies that the AuthenticationState won't change. But again, only seeing your code can enable better answers.

[aiqoo]

enetstudio Thanks for the answer

I still experience the technology and want to check things out.

In a real environment, I do not intend to validate using JWT

The fact that I can implemente auth only through EF its limit me in terms of my organization and work environment.

I will have to find a solution that will work with MYSQL and there is currently no such one for .core 3.0

Thanks in advance

[enetstudio]

"In a real environment, I do not intend to validate using JWT"

"The fact that I can implemente auth only through EF"

I guess you mean implementing authentication on server-side Blazor, right ? You can use Windows Authentication as well.

Incidentally, you do not implement authentication via EF, which is an ORM framework. You probably meant the Identity system...

[aiqoo]

"Incidentally, you do not implement authentication via EF, which is an ORM framework. You probably meant the Identity system..."

yep....

[msftbot[bot]]

Thank you for contacting us. Due to no activity on this issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.