Implementing authorization in Azure with AAD and AAD B2C, is this architecture sound?

Question

I'm tasked with building a multi-tenant product platform and I'm having a hard time deciding how I should implement authentication and authorization. Mostly I'm confused about AAD capabilities and best practices. The project is not for a big enterprise but a small scale greenfield project. I'm looking for answers to my questions and feedback on the authentication and authorization architecture.

I have some requirements to fulfill:
R1. No local users, all users belong to an external company and should authenticate using their current IdP (Google, Microsoft account).
R2. Good security practices. (Zero trust and granular access management RBAC)

So my current understanding is that in order to achieve secure communications between my cloud resources above I should utilize Managed Identites (System Assigned), issued from "My Company AAD" in the picture above.

Questions/statements:

1. In order to authenticate users without needing to store their data, I think I should utilize an AAD B2C. In this AAD B2C I will add a new tenant which will be something like "MyCompanyB2C", and I should not add a new tenant in AAD B2C for each new customer we sign, correct?
2. Do I need to federate with the external IdP to make enterprise accounts work for sign in?
3. Do I define the custom scopes for RBAC in the AAD B2C? (E.G, "users with the claim scopes: "users/read" can read user data").
4. Will access tokens from my AAD B2C share a uniform format, even though my customers can use different IdPs? (I.E, can my app have a single uniform authorization method, I don't have to support "Google access tokens and Microsoft access tokens" in my app authz).
5. In order to not issue "almighty access tokens" for users with all scopes needed for all downstream dependencies, the services should only call each other with tokens issued for the micro-service with scopes for the depending service. Is this neccessary if we already implemented Managed Identites between resources?
6. "AAD B2C" is the authorization/authentication server responsible for issuing OIDC access tokens?

References:
Apply the verify explicitly Zero Trust principle to your API implementation

Answer 1

I'll answer this based on standard OAuth design patterns:

A1

AAD B2C is an authorization server (AS), which is the role you need. It belongs to you and protects your data. It can authenticate users in many ways, including external IDPs, eg Google. After external login it is common to create a user record in the AS.

After login you will call APIs with access tokens that contain a subject claim. Do you then need to store business resources against users? Eg products purchased? If so you need a stable subject claim - it is worth thinking more about that.

A2

The AS can federate to an enterprise IDP, when provided. If an enterprise chooses not to provide one, you can give them a default login method managed by the AS, eg passwords. This will store a user record in the AS.

A3

Yes - custom scopes and claims are defined in the AS where you can control them. They are issued to access tokens and you use them in APIs to control access. In your case you may need a tenant_id claim, so you need to think through how tenants get assigned to users.

A4

Yes - that is a key point of using an AS. Your apps run a code flow to the AS, which receives external tokens, then issues AS tokens to your apps.

A5

An optimal way to manage microservices from the same owner is often to forward access tokens between them. This flows the user identity in an auditable way and enables user based authorization in each API. It should be combined with good use of scopes and claims in APIs, and assigning of scopes to clients. Eg if a client is given scopes orders shipping, its access token would be rejected if sent to a payments API.

A6

Yes - as above.