Aspnetcore.docs: Confusion about needing 2 apps

[SaebAmini]

Why is there a need for a separate Server and Client app registration at all? considering the majority of ASP.NET Core hosted SPAs are served from the same "app", wouldn't it be simpler to just go with a single app registration for the sake of this guide? or am I missing something here and you actually require the 2 apps?

---

Document Details

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

• ID: 3039ff79-ee86-20b1-0082-d3899a84c823
• Version Independent ID: af4a3a75-ae52-5f6d-2120-737bc2fefb07
• Content: Secure an ASP.NET Core Blazor WebAssembly hosted app with Azure Active Directory
• Content Source: aspnetcore/blazor/security/webassembly/hosted-with-azure-active-directory.md
• Product: aspnet-core
• Technology: aspnetcore-blazor
• GitHub Login: @guardrex
• Microsoft Alias: riande

[guardrex]

Hello @SaebAmini ...

AFAIK, the concept is that a single server API could satisfy the requests from more than one client-side app with each client-side app having a separate registration with different access/permissions configured on the Azure side. This is also the more complicated setup of the two approaches (one registration vs. two or more). Yes tho ... AFAIK ... you can use a single registration if you wish. Ping @javiercn ...

• Any caveats to a single Azure registration both client and server apps?
• Should we say something about the possibility of using a single registration in the topic and why the topic is using two registrations? If so, what would you like to say?

[javiercn]

Why is there a need for a separate Server and Client app registration at all? considering the majority of ASP.NET Core hosted SPAs are served from the same "app", wouldn't it be simpler to just go with a single app registration for the sake of this guide? or am I missing something here and you actually require the 2 apps?

Applications in OAuth don't map 1:1 to applications/processes. In the case of SPAs specifically, there is a significant difference WRT security between code that runs in the browser vs code that runs in the server.

The API is a resource that is hosted on a server, and in the future you might grant that API additional permissions to talk to other APIs or perform other actions based on the fact that it runs on trusted hardware, or allow it to perform other authentication flows that are not suited for a SPA running on the browser.

In this model, an API is a resource and defines a bunch of scopes, you can't authenticate with an API because it doesn't make sense (no redirect url enabled, so no auth flows), while the Blazor app is a Client, that can authenticate (with a set of restrictions, like not being able to get refresh tokens) and request access to some resources on the server by requesting scopes.

You can technically put everything on the same app, but the moment you change things, there is a good chance you make a mistake that grants unnecessary permissions to code running on the client. Additionally, if you need to invalidate all access tokens and so on for an app, it is much easier to recreate just the client app than to recreate all of it.

There are more reasons, but these are a few of the top of my head, the key takeaway is that OAuth app != process

[guardrex]

Should I seek to place a version of your remarks in the Blazor WASM security overview topic? A good spot for it is near where we branch off to the various hosted scenarios at ...

https://docs.microsoft.com/en-us/aspnet/core/blazor/security/webassembly/?view=aspnetcore-3.1#implementation-guidance

[javiercn]

No, I don't want to turn our docs into an OAuth tutorial. If we get more feedback around this, maybe I'll consider writing a separate topic

[SaebAmini]

Thanks, @guardrex and @javiercn for taking the time to explain. Your explanation makes sense. I think my confusion comes from a whole bunch of other places which just go with a single app registration (I'm pretty sure I've seen it even on other Microsoft docs).

I wouldn't go as far as turning the docs onto an OAuth Tutorial, but I do agree with @guardrex's suggestion that it'd be worth having a short note in there about _why_ we need two app registrations in this SPA-API model. It can be as simple as "because security!" (well maybe a wee bit more than that 😃), but the idea is to hint to the reader that this decision is intentional and valuable and can save you from shooting yourself in the foot. I think that'd be an important thing to call out in the "Security" docs, considering the points you mentioned.