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