Secure data with Interactive Auto rendering

[guardrex]

Fixes #34586

Thanks @davisnw! 🚀 ... Your product unit issue (dotnet/aspnetcore #60184) will be reviewed by engineering for possible improvements to the framework in a future release. For the docs, I'm making the following updates:

• Cross-link existing sample apps that demo secure web API into the Call web API article.
• Add a section to the security node's Overview article on Auto render mode components/apps that adopt the two-service approach. Cross-link the new section in relevant locations.

I decided not to change the existing Call web API sample apps at this time. We have enough security examples that make secure web API calls, including WASM and server-based examples, to cover it. The problem was just that most of the samples are new and unlinked ... not anymore after this goes in 😄.

I'll get a security review on this PR. I'm not too concerned about my general remarks. I'd like to hear from any or all of Javier, Stephen, and Mike on the language used at the end of the new section. I'd like to know if they want to say something different or add guidance to it.

---

Internal previews

📄 File	🔗 Preview link
aspnetcore/blazor/call-web-api.md	aspnetcore/blazor/call-web-api
aspnetcore/blazor/components/render-modes.md	aspnetcore/blazor/components/render-modes
aspnetcore/blazor/security/blazor-web-app-with-entra.md	aspnetcore/blazor/security/blazor-web-app-with-entra
aspnetcore/blazor/security/blazor-web-app-with-oidc.md	aspnetcore/blazor/security/blazor-web-app-with-oidc
aspnetcore/blazor/security/index.md	aspnetcore/blazor/security/index

[halter73]

@javiercn Is this the best way to use PersistentComponentState? Is there any risk of PersistData getting called before GetWeatherForecastAsync completes?

[javiercn]

It could happen if the application is shut down before GetWeatherForecastAsync completes

[guardrex]

@halter73 ... Is your question for @javiercn ☝️ blocking? You know, that code is directly out of the sample apps.

Otherwise if you and @mikekistler don't see any problems, particularly with my remarks at the end of the new section, we should be able to merge this fairly quickly.

My main concern is this language ...

The preceding approach works well when the security requirements of the web API match the security requirements of the component. For example, the same authorization policy can be applied to both the web API endpoint and the component.

Complex scenarios require additional planning and implementation. For example, a server web API that has multiple callers with different access permissions either requires a more sophisticated authorization policy, one or more additional policies, or additional endpoints with different access requirements.

As you build security into apps that adopt Interactive Auto rendering, be mindful that the security implemented for the server's web API endpoints doesn't secure the server's service implementation that's used when a component is rendered on the server and accesses data through the service. Carefully weigh the difference between accessing data on the server during SSR versus accessing the data on a client web API request during CSR. Strategically apply security to avoid improper access to data.

• Is it correct?
• Should we add or subtract anything?

[guardrex]

Ping @halter73 ... Is this blocked on your question? Otherwise, is there anything wrong with the guidance at the end of the section ☝️.