IMovieService example can lead to authorization problems

[davisnw]

Description

The page gives an example of creating a common interface IMovieService with two implementations: ClientMovieService and ServerMovieService.

Neither the page nor the linked github code example (BlazorWebAppCallWebApi) have any discussion of the ASP.NET Core endpoint authorization.

So, for example, since ClientMovieService goes through "web api", traditional authorization attributes such as [Authorize("MyPolicy")] could be applied to individual endpoints (so e.g. Updating a movie has different permissions than reading a movie), however, the same operation in SSR going through ServerMovieService implementation would not have any of those authorization attributes applied.

This bifurcation of authorization stacks seems like an area rife for security holes, so some discussion of handling authorization when providing multiple implementations of a service for client-side vs server-side rendering seems to be warranted.

To further add to some of the confusion, in the github sample (BlazorWebAppCallWebApi), there is a tremendous amount of duplication in the minimal api spec and the ServerMovieService:

git difftool dbca3f4:9.0/BlazorWebAppCallWebApi/BlazorApp/BlazorApp/Program.cs dbca3f4:9.0/BlazorWebAppCallWebApi/BlazorApp/BlazorApp/Services/ServerMovieService.cs

So now there are actually 3 separate implementations of the movie related functionality.

Page URL

https://learn.microsoft.com/en-us/aspnet/core/blazor/call-web-api?view=aspnetcore-9.0

Content source URL

https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/blazor/call-web-api.md

Document ID

c7e59a08-1c60-32c2-75fd-33cb77ff7a5d

Article author

@guardrex

Metadata

• ID: 8b5e2e10-ff7b-2b9f-84da-f16028ae2c53
• Service: aspnet-core
• Sub-service: blazor

Related Issues

[github-actions]

💃🕺🥳 Happy New Year! 🎈🎆🍾🥂🎉

Stand-by! ... A green dinosaur 🦖 will be along shortly to assist.

[guardrex]

Hello @davisnw ... Let me get back to you on this, hopefully tomorrow morning (Thursday).

[guardrex]

I'm back! Sorry for the delay.

Neither the page nor the linked github code example (BlazorWebAppCallWebApi) have any discussion of the ASP.NET Core endpoint authorization.

It's not covered here at the moment. Secure web APIs are covered by the main doc set articles, which apply to most Blazor scenarios (especially on the server-side), and the Blazor node Security and Identity articles.

I want to mention in passing that a goal for the Blazor sample apps was to include secure web API calls. Devs can follow the patterns for typical secure web API call scenarios. Here are the examples:

• Standalone Blazor WebAssembly with Identity: Includes two secure data processing endpoints, one of which has an auth policy applied. The article covers cross-domain/same-site concepts and antiforgery.
• BWA with Entra: Includes a secure weather forecast web API.
• BWA with OIDC: Includes a secure weather forecast API for both the non-BFF and BFF patterns.

I agree with you that this article and the sample apps for it should include basic security patterns. I'll schedule this issue for work, and I hope to reach it within the next couple of weeks.

Notes for updating the article and samples:

• Address your concern, namely that "some discussion of handling authorization when providing multiple implementations of a service for client-side vs server-side rendering seems to be warranted."
• "there is a tremendous amount of duplication in the minimal api spec and the ServerMovieService": Yes, I agree. I'll resolve this problem.
• Add basic web API security scenario coverage for typical apps into the text coverage.
• Add the scenarios described to the sample apps.
• Cross-link the examples in the existing Blazor samples.
• Cross-link the extended coverage in the Blazor Security and Identity node.
• Improve the organization of coverage.

On your last point, you wrote ...

So now there are actually 3 separate implementations of the movie related functionality.

I don't follow. There's the service for server-rendered components (SSR), and there are the endpoints for web API calls for CSR. The "Backend" app only manages Todo list examples. What's the third "implementation" that you're referring to for the movie examples?