While you weren't paying attention, Microsoft updated Azure AD B2C to use Microsoft Graph. Here are the implications to that very significant change.
good news is, we were all delightfully wrong in this assumption.
As of July 2020, Azure AD B2C meter IDs were changed to new GUIDs with a new name of "Azure Active Directory B2X". As SecureCloudBlog points out, there's a shift into a new product called Azure AD External Identities. In the Azure Documentation,
External Identities is a set of capabilities that enables organizations to secure and manage any external user, including customers and partners. Building on B2B collaboration, External Identities gives you more ways to interact and connect with users outside your organization.
Azure AD B2C seems to have a place in this as well:
Azure Active Directory B2C provides business-to-customer identity as a service. Your customers use their preferred social, enterprise, or local account identities to get single sign-on access to your applications and APIs.
They seem to fit together in the discussion of external identity scenarios, mostly in a way to discern the two, as the documentation seems to lay them out in equal levity. It also seems to be a way to either simplify or consolidate B2B and B2C pricing into one SKU.
This is a much more complicated process for B2B, as outlined here. With the vast frequency of Azure AD vendors and customers interacting with each other, it was a natural evolution for things to escalate from inviting external users in bulk (which you can still do, technically) to having a more structured and secure process for adding said users.
The BIG change for B2C users, however, exists in the Graph API back end.
It appears that around October 2020 or so, Microsoft switched all existing Azure AD B2C customer from Azure AD Graph API to Microsoft Graph, or at least the B2C version of it. This version of Microsoft Graph limits you to API interactions on:
Despite the massive amount of feedback given to Microsoft in the Azure AD B2C space requesting simple group-based authorization policies, it appears that we are getting some weird version of Trust Framework policy instead, which is far more complicated - and harder to implement good authorization policy around - to the point where it really doesn't make any sense.
The best - and only - solution for authorization policy for users at this point is to build something application-specific that occurs at a point after the authentication process. We've outlined a solution here that initially involved the old Graph API, but since that is no longer a choice, the best option is to find a way to make it work without the Graph API dependency (Azure Tables or your preferred method of user info storage).
This is really disappointing, given the amount of feedback given to Microsoft regarding role-based authorization from the directory. If you follow Microsoft's documentation, .NET Core applications support both Role-based and Claims-based authorization - it's just that the two cannot intermingle at any point.
So, given that 'constraint', you'll have to factor your applications accordingly.
Looking for help building or integrating your web application with Azure AD B2C? Contact us for a quote - not only is it free, but we can help you find what you're looking for at a better price than most consulting firms!