I want to build 2 apps.
Private API in .NET that takes care of database access / processing of data.
Blazor WebAssembly app which will connect to this API securely, to search data.
Since Blazor WebAssembly DLLs can be decompiled, I can't use any private/secret keys in the APP.
I don't want anyone being able to use the API if they discover the endpoints. Only the Blazor APP can use the API (and any other app I might build in the future).
How should I approach this? Is it even possible to do it securely or should I go Server Side?
Secure ASP.NET Core Blazor WebAssembly explains how to secure a Blazor WASM app
Blazor WebAssembly 3.2.0 Preview 2 release now available explains how to use IAccessTokenProvider to get the access token to authentify your applicaton on API.
Related
I have a project structure which includes a Blazor server project and an api project.
Every things works fine, but I'm confused about how to handle security. I use JWT in the api, and in Blazor server I use scaffold identity.
How can I integrate the security between the two project?
Should I use JWT for both and override authentication state provider?
https://www.pragimtech.com/blog/contribute/article_images/1220200705121732/blazor-application-architecture.png
#edit
I don't want to use the Identityserver4 as the version 5(duendesoftware) will be paid , the support for identityserver4 will be terminate at Nov 2022 with the end of .net core 3 support, So that I need any replacement that's free
or a cimple way to do the authentication between the two layer
Thanks
I have a hosted Blazor WebAssembly App and I tried to scaffold identity server in the project App.Server. It's working but now I have a mix of cshtml view files in the App.Server (which was intended to be only a asp net core web api). I found hard to integrate the Blazor UI and cshtml files to have a nice user experience.
I was expecting to have a separate pure web api with identityserver api and Blazor taking care of the pages/views and api calls. Is it possible to move those cshtml to Blazor and manage the pages from there or the scaffolding has been done that way because is not?
No, you can't move those Razor Pages pages to your front-end Blazor. But you can design them in such a way as to create the impression that, when the user, for instance, is redirected to the Login page, the Login Razor Pages page is part of the Blazor front-end. I've seen an example of that, and must admit that I couldn't discern it without seeing the source code.
Having a dedicated Web Api project or having Web Api end points in your Blazor server project has nothing to do with the Identity UI not being part of the Blazor front-end.
I was expecting to have a separate pure web api with identityserver api and Blazor taking care of the pages/views and api calls.
You can create a Blazor WebAssembly stand alone project, add a Web Api project, and an IdentityServer4 project, in which case, the flow of OpenID Connect is such that your users wanting to log in are redirected to the Login page provided by the default template of the project, but you can still design the pages to look as though they are part of the Blazor front-end.
The only viable solution that can satisfy your whims is to use Bearer Authentication; that is your Web Api produces Jwt token for users, which are passed to your front-end, and stored in the local or session storage. In that case, your Login page can be a Razor component that gather credentials from the user, and pass them to the Web Api appropriate end points via the Fecth API (this is the HttpClient service in Blazor)... This was the method we adopted before the Blazor team have created the current authentication system of Blazor. Personally I wouldn't recommend one to do that unless he is proficient in Blazor and other fields, and he's ready to invest a great deal of time for developing it. I guess your solution should be deception: let the user think that he's never left the space of the Blazor SPA...
So I'm coming from Xamarin world trying to build a Blazor App. And I'm struggling with a high level understanding of why Blazor Apps ( client side only ) cannot make a basic HTTP get call to say google.com or any other http get/post call to different resources/urls?
Can someone break it down for me, am i crazy? how would i ever implement maps.google.com or other http request I'm going to need to make.
I do notice anything with a package, like SendGrid or B2C or Cosmos Nuget Packages seem to work fine... how do they get around the different domain names ?
Can i simply say on my webserver : (in English) - allow requests to google.com and someoneElsesApi.com
or would i have to contact google and have them allow my Blazor app to make calls?
Just really struggling with how to use Blazor Client Only PWA app if it cant connect or call to anything else on the web... seems pointless if a Blazor app cannot make any http calls to other services.
Ok, so yes... I found an Public Open API to test a request against, and it does work from a Blazor WASM (Client only). More specifically the below works just fine..
#inject HttpClient HttpClient
...
string responsString = await HttpClient.GetStringAsync("https://rickandmortyapi.com/api/character/5");
The problem i was having which seems confusing:
Both
Blazor WASM
Xamarin Forms apps
can both call an open public Web API just fine from HTTP Client.
But...
When I create an ASP.NET core API and publish it allowing anonymous access in azure,
Xamarin Forms can call that API
Blazor WASM cannot call it unless i specify CORS correctly in the Web API
So with my inexperience with Blazor WASM i assumed it could not do this.. while Xamarin can. So this changes to ... how is it that the Web API i created in Azure + ASP.net Core Web API - just allows the Xamarin App to call it (without CORS specification)... while CORS Must be set correctly for a Blazor WASM?
There seem to be plenty of tutorials on how to use third-party authentication providers for Blazor WebAssembly, but there doesn't seem to be a documented process for using Windows Authentication (on-site Active Directory domain) from an ASP.NET Core hosted server.
Is this actually possible? I would like the Core server to authenticate the user with the roles and policies, and for this information to be accessible from the WebAssembly client also. I understand that the Client can only use authentication to show/hide UI elements, and that any actual securing should be done on the Server, but is there a way to access the Windows authentication/authorization from both sides of the application?
I've seen that Azure App Service mobile apps can implement authentication for multiple identity providers via a single client SDK. If an app hosted on Azure App Service is using ASP.NET Core in the cloud, though, can its UWP or Windows Store client app also benefit from multiple identity providers via a single client SDK?
If yes, then how does that work? Does it use the same mobile client SDK?
If no, then how would I authenticate such a mobile client? Will I have to use individual provider SDKs?
I know ASP.NET Core is still prerelease, but I'm wondering:
What multi-provider authentication functionality is available from a mobile client now?
What such functionality is planned to be available when ASP.NET Core 1.0 is finally released?
What such functionality will likely be on the roadmap for the future?
Azure App Service provides authentication as a service. In other words, the client authenticates to the service, and the service passes on the authentication to you.
Underneath, the app service passes a number of authentication related app settings within environment variables that you can read via the normal method. The original JWT is also passed in via the X-ZUMO-AUTH header.
For your clients, probably the best way is to use the Azure Mobile Apps client SDKs - there are clients for .NET (Xamarin, UWP), JavaScript, iOS and Android. You don't need the data access functionality - just the client creation and login / loginAsync method calls.
For your server, take a look at the Authentication Overview for more information. You may also want to read some of the info in Chris Gillums blog for more technically details.