我不明白应该如何使用 Azure B2C 中的“范围”。它们与 API 相关联，但与用户无关。我确定我遗漏了一些东西，但我认为与 API 相关的东西没有实际用途。我已经使用并实现了基于用户在数据库中的角色的基于声明的身份验证。
例如：API 的普通用户不应该拥有删除对象的权限，但管理员应该拥有删除对象的权限。有人有一个实际示例说明如何使用这些 B2C“范围”来限制用户对 API 的访问？
【问题讨论】：
标签： azure-ad-b2c
它们与 API 相关联，但与用户无关。
没错。我喜欢将与 API 的关联视为定义 API 的'表面积'。例如，this API 定义了 2 个作用域
readwrite现在，您可以定义两个应用程序。一个应用只有读取权限，一个应用有读写权限。
对于一个 Web 应用和一个 Web API 的常见用例，它没有任何价值。对于这种情况，我一直在使用no-op 的范围。
我已经使用并实现了基于用户在数据库中的角色的基于声明的身份验证
您可以使用custom attributes 为用户分配“角色”。您可以通过Azure AD Graph API 设置它们以确保它们的设置安全。你也可以set them during sign-up（不过这涉及到更多）。
当您为该用户请求访问令牌时，您定义和设置的自定义属性将在 API 中可读以检查权限。
评论反馈
如果我提升或降级用户，我需要更改他们在客户端访问的端点（策略）。
无需更改政策。您将通过 Azure AD Graph API 更新该用户的自定义属性。
我的问题是我对授权端点（“范围”）而不是用户的身份验证系统感到困惑
是的，我也是！我认为这可能与产品的目的有关。 B2C 是关于自助注册、密码重置和与其他 IDP（如 FB、Google 等）联合。当您想要控制用户的权限时，也许 Azure AD 是一个更好的解决方案。不确定，还在学习中！
我仍然看不到根据安全性将 API 分成几个不同部分的实用性。 API 应该是功能相关服务的集合
您不会拆分您的 API。您可以拆分使用 API 的应用程序。见上文。
文档参考：Requesting access tokens、GitHub Issue 以改进文档。
【讨论】：
角色和范围为这个用户访问控制提供了两半。
角色——例如Administrator、Member和Guest——确定是否允许经过身份验证的用户删除对象。
范围 -- 例如 read、write 和 delete -- 确定授权应用程序是否可以代表授权/同意用户删除对象，如果该用户通过其角色分配是允许这样做。
Azure AD B2C 目前不支持管理角色以及将角色分配给用户。
不过，它确实支持管理范围并将它们分配给应用程序。
【讨论】：