Update Doc for Blazor .Net 8

[kevingates]

It looks like the version 7 of Duende docs appears the same as version 6. (Example, under "Modifying the Front-end Part 2" you see in the code: namespace Blazor6.Client.BFF;

Are there any special things to be done as it relates to the various Render Modes? I know the InteractiveAuto lets it switch between Blazor Server and WASM.

Does this require any special setup to handle this switch smoothly?

Version 7 (for .Net 8): https://docs.duendesoftware.com/identityserver/v7/quickstarts/7_blazor/ Version 6 (for .Net 6): https://docs.duendesoftware.com/identityserver/v6/quickstarts/7_blazor/

[kevingates]

@damianh @leastprivilege (just looking at members of this repo), do either of you have educated guidance on how to make this work properly on .Net 8? We're using Interactive Auto (so Server and WASM) set globally. I've seen the docs and then your source code (which is slightly more modern), but still out of date too as it uses CascadingAuthenticationState, which is no longer a thing in .Net 8 in addition to other things that are different in .Net 8 (Interactive Auto for instance). See repo here: https://github.com/DuendeSoftware/Samples/tree/main/IdentityServer/v7/BFF/BlazorWasm

It looks like maybe it took a .Net 7 repo and updated it, but things are different in .Net 8 templates and how they do things.

I appreciate any guidance you may have to offer. This is all new to me.

[josephdecock]

Blazor interactive auto mode is quite complex, and it's been my intention to provide updated guidance - along with more tools to support it - for a while now. Our docs are in need of updates, which have been waiting on said tooling updates. I know there's a lot of interest in this, and I'm sorry for the delay!

The complexity in interactive auto mode comes from the fact that the interactive mode switches between server side rendering, blazor server, and blazor wasm dynamically, and each of those modes has a different threat model and significant differences in the mechanics of their implementation.

SSR has http requests and responses, and is secured with cookies. We start off with a "normal" web app.

Blazor server streams ui updates over a socket, so there are no http requests and responses and therefore no cookies. This means that you need a server side store of tokens so that you can do token management without cookies.

WASM is all in the browser, so has basically the same threat model as a traditional SPA. This means there are http requests and responses again, but it also needs a BFF layer for security and potentially to handle 3rd party cookie blocking.

Complicating all of this is that you can't guarantee when tokens will be refreshed or when other updates to the session will occur AND you don't know when the transition from server to wasm will occur.

If that all sounds like a lot of complexity - I agree!

The architecture that we recommend for interactive auto blazor is basically a hybrid of all of this. You need a server side token store and you can use that directly in blazor server or SSR. But you also need a BFF for your wasm, and you need it to use the same server side token store so that token and session management results are consistent.

The next major version of our BFF package is going to include tooling to help with this. It's not available yet, but hopefully previews will be available "soon" (sorry, no official timeline announced/committed to yet).

It's not an officially supported sample, but some early work on this topic is in a personal repo of mine here: https://github.com/josephdecock/InteractiveBlazorAuth. I think it shows the architecture pretty well, as well as kind of highlighting why better tools would help (hopefully coming soon to a BFF near you!)

[kevingates]

@josephdecock : that is an incredibly thorough reply and I sincerely appreciate your work on the project, the upcoming changes, and the details of the updates.

I know you can’t answer this definitively for everyone but is it fair to assume that if we’re on an enterprise application that it may be safest / wisest in the short-term to do the Interactive WebAssembly render mode (not auto) to then use the existing guidance (with slight modifications)? Then once the newer version releases, migrate to Auto at that time?

From the way it sounds, I am thinking that’s the safer option.

I don’t believe I saw guidance on the site for Blazor Server mode so I think WASM is probably the most straightforward route per existing documentation.

Once more, thank you again.

[josephdecock]

Starting out without auto but looking to move to it eventually is generally what I would be in favor of.

You wouldn't have to use WASM though. You could also use Blazor Server. The basic tradeoff is pretty well-known: blazor server uses lots of memory server side, while wasm requires a large initial download of the bundled javascript. If you wanted to use blazor server, you can use the open source Duende.AccessTokenManagement library. We have documentation and a sample on github:

https://github.com/DuendeSoftware/Duende.AccessTokenManagement/wiki/blazor-server https://github.com/DuendeSoftware/Duende.AccessTokenManagement/tree/main/samples/BlazorServer