这不像Microsoft Entra ID（以前的Azure AD）那样开箱即用，但是有一些方法可以通过一些支持基础设施来实现这一点。
这些建议既适用于通过REST API technical profiles的自定义策略，也适用于在发送令牌之前使用API连接器的用户流。
1.在外部数据库中保存客户端ID、用户ID和角色的Map。例如，SQL DB。成功登录后，获取用户角色并将其添加到JWT，然后将其发送到依赖方应用程序，后者应验证令牌和所需角色。注意，如果使用自定义策略，则可以停止用户并在Azure AD B2C中显示阻止屏幕。

• 虽然没有在UI中显示，但您仍然可以使用Microsoft Graph添加RBAC分配并在登录时读取它们。这有点复杂，但你可以通过以下方式找到示例：
• John帕特里克丹迪森（前微软身份识别Maven）b2c-appRoles，
• Christer Ljung（Microsoft FTE）B2C-AppRoles，以及
• Denis O Azure B2C Role based Authorization Tutorial
• Azure-AD-B2C社区存储库Authorization-AppRoles

这两种实现都需要一个API来将角色读/写到持久性存储（即数据库或目录）
您的应用还可以调用数据源来获取用户拥有的角色并决定如何处理该用户。通常，这很好地位于OnTokenValidated Microsoft Identity Web事件中。

您可以将Conditional Access用于用户流和自定义策略，具体取决于您使用的是哪种策略。
启用后，请设置适用于相应应用的策略，排除特定用户或组，并将其设置为阻止。这将阻止所有 * 其他用户 * 或不在选定组中的用户访问该应用程序。
请注意，条件访问策略在首次创建时可能需要一段时间（有时一个小时或更长时间）才能生效。