Aspnetcore.docs: Securing a Blazor WebAssembly hosted app with an external IdentityServer

[Ef0Dev]

The current documentation on securing a Blazor WebAssembly hosted app with IdentityServer seems to focus on installing/configuring IdentityServer within the Blazor app itself (in the server app).

Any thoughts on updating the documentation to cover authenticating with an existing, external IdentityServer4 provider?

Docs for the standalone WebAssembly app cover using the AddOidcAuthentication middleware in which you can specify an external authority, but nothing is mentioned about this for hosted apps.

Also, nothing I can find in the documentation for the above middleware covers how to pass acr_values (such as the tenant) in the request to the external IdentityServer - and in playing around with the middleware myself, I'm not seeing a way to do this (is this simply something that isn't supported?).

Thanks.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 9638772f-0f1e-c2a9-8a58-ae8c3e37ae28
• Version Independent ID: 7a5b169e-08cb-cdba-4501-88d3da2723bb
• Content: Secure an ASP.NET Core Blazor WebAssembly hosted app with Identity Server
• Content Source: aspnetcore/blazor/security/webassembly/hosted-with-identity-server.md
• Product: aspnet-core
• Technology: aspnetcore-blazor
• GitHub Login: @guardrex
• Microsoft Alias: riande

[guardrex]

Hello @Ef0Dev ...

updating the documentation to cover authenticating with an existing, external IdentityServer4 provider

The concepts are the same. Devs can follow the client configuration guidance in the topic. The only difference is that the HttpClient base address won't be based on IWebAssemblyHostEnvironment.BaseAddress (builder.HostEnvironment.BaseAddress) ... it will be to the address of the server. I think this is worth calling out in the topic.

using the AddOidcAuthentication middleware in which you can specify an external authority, but nothing is mentioned about this for hosted apps

A Blazor WebAssembly app in a hosted solution is the same as a standalone Blazor WebAssembly app. The only difference is how it's served. OIDC concepts are the same. The hosted topics for Azure (AD and AD B2C) use additional API (Microsoft.Authentication.WebAssembly.Msal), which means that the dev has to write less code.

nothing I can find in the documentation for the above middleware covers how to pass acr_values (such as the tenant) in the request to the external IdentityServer

Open that for engineering at https://github.com/dotnet/aspnetcore/issues. There might be a way to do it that we can cover, or it might be a feature request that they'll take on for a future version. Please add a cc: @guardrex to the bottom of your opening comment so that I can follow the discussion.

Leave this issue open. I'll add a remark about the HttpClient base address to the client config section of the IdS topic. This issue will close automatically when the PR merges. Thanks for your feedback on the topics.

[psiservices-mhart]

@guardrex - Thank you. I will raise the issue about ACR values with the engineering team and cc you as requested.

In regards to the rest:
I appreciate your modifications. I think one of my disconnects is that the docs assume you have created the app with Authentication included (and indeed they instruct you to at the top). However, for someone who wants to use an external identity server as I do, scaffolding with Authentication doesn't seem like something you'd want to do, since the only option currently is
Store user accounts in-app - Select this option to create a project that includes a local user accounts store.
If I am trying to work with an external identity server, then clearly I don't want to store user accounts in-app. Therefore I did _not_ choose the option to scaffold with authentication.

Keeping the above scenario in mind:

• hosted app
• external identity server

• no authentication scaffolded

  I think that's when the docs become a little less clear to me.

• Right off the bat, the docs start out with instructions to scaffold with authentication/storing user accounts in-app - not applicable to my scenario.
• Under Server app configuration, much of that doesn't apply to my scenario either. You said,

Devs can follow the client configuration guidance in the topic.

If the intended path through the doc page (for the above scenario) is actually to disregard half of it (ie; the server app configuration section), this is why I raised the question that maybe this scenario warrants its own topic, or at the least, a little more clarity. As it stands, it's unclear whether _anything_ covered in the server app Startup class section applies given the above scenario. Some of it _obviously_ doesn't (the first two code samples for instance), but with some of it it's less clear.

A Blazor WebAssembly app in a hosted solution is the same as a standalone Blazor WebAssembly app. The only difference is how it's served. OIDC concepts are the same.

That makes sense. The reason I questioned whether the middleware was dependent upon the hosting model you chose was because I noticed the hosted app doc page exclusively describes using the AddApiAuthorization() middleware, while the standalone app doc page exclusively describes using the AddOidcAuthentication() middleware.

Is the difference between these two pieces of middleware roughly that

• AddApiAuthorization() loads the authentication config via http?
• AddOidcAuthentication() takes the authentication config options directly or gets them from a JSON file?

If this is the case, I assume for hosted you can use either, and it really just comes down to preference? If this is the case, I really think it'd be helpful to call this out.

One other thing I found a little unclear: If you are using an external identity server and thus do NOT scaffold authentication, there is a lack of clarity on working with the AddApiAuthorization() middleware. If I am understanding correctly, AddApiAuthorization() loads the authentication config via HTTP, and the URL defaults to _configuration/{client-id}. If you _had_ scaffolded with authentication, this would map to the server app's OidcConfigurationController. However, if you do _NOT_ scaffold with authentication, this controller & route do not exist. Now, the docs state the middleware can be configured "to point to a separate endpoint by calling the overload with options." But there is no indication of precisely what that endpoint is expected to return. (I needed to create and debug a separate sample app with authentication scaffolded in order to figure out where the _configuration/{client-id} route the docs mentioned was even coming from.) Again, I think this disconnect is because the docs are geared towards authentication having been scaffolded.

I fully appreciate that the docs cannot possibly hope to cover every scenario that's out there. However it seems like the scenario I describe above (hosted, external identity server, no authentication scaffolded) would be pretty common.

As always, thanks for being receptive to community feedback.

[guardrex]

Updating my answer here given that I was tricked a little bit by the coverage: Although a hosted WASM app (the client app) is just a standalone+served WASM app, it _wouldn't be configured_ in standalone config (or in a hosted solution without Identity/IdS) as the client app of a hosted IdS solution (sans IWebAssemblyHostEnvironment.BaseAddress) described by this topic. It would actually be configured as a standalone WASM app according to our standalone guidance. This is surprising to me, but this is the way devs should go. I apologize for my wrong (but entirely logical) guess. It might even work in practice, but it isn't a supported approach even if it did work. I'm going to surface this guidance via cross-links and remarks shortly (today, 7/15) on #19208.

[psiservices-mhart]

Thanks @guardrex ! That small thing actually adds so much clarity (both for me, and for others in the future I think).

The only thing I think is left out in simply pointing this scenario to the standalone docs, is that while that covers the client app, it leaves out the server app in the hosted model entirely. The server app _is_ still going to have some authorization setup work involved to handle requests coming in from the client app. But I assume at that point the server app is like any other asp.net core web API (I am guessing there is authorization documentation for that somewhere already?).

Oh and sorry if I added any confusion in replying with a different account. Ef0Dev and psiservices-mhart --> both me.

[guardrex]

Unfortunately, it's beyond the scope of my knowledge. Given that it's _security_ (and my track record guessing things here thus far isn't so good 🙈:smile:), I'll defer to experts. I can say that our own web API doc links off to the IdS docs for coverage of web API with ASP.NET Core and IdS. In order to get the server app to auth the client requests, I suspect you'll need to find docs over there and elsewhere. I don't think we have that coverage. Your best bet for further support is to reach out to devs on support channels ...

• Stack Overflow
• ASP.NET Core Slack
• ASP.NET Gitter

[Ef0Dev]

Totally fair! Thanks again!