.NET Core Web应用中Azure AD B2C声明可用于授权吗？

1. 直接使用extension_TeamId声明判断用户租户归属的安全性 #

微软官方文档明确说明：ID Token由授权服务器颁发，包含承载用户信息的声明，可与Access Token一同发送或替代Access Token返回；ID Token中的信息用于客户端校验用户身份，供第三方应用识别用户，ID Token不可用于授权场景，仅Access Token可用于授权；ID Token提供的声明仅可用于应用内交互体验展示、作为数据库键值、控制客户端应用的接入权限。

不存在用户伪造该声明值冒用身份的风险，前提是你使用官方提供的认证中间件完成标准的Token校验流程。
.NET Core 接入Azure AD B2C时，Microsoft.Identity.Web中间件会自动完成ID Token的全链路合法性校验：

• 验证Token的数字签名确由对应B2C租户颁发
• 校验Token的受众（aud）匹配你当前应用注册的客户端ID
• 校验Token的颁发者（iss）为合法的B2C租户端点
• 校验Token在有效期内、未被篡改

校验不通过的请求根本不会生成合法的ClaimsPrincipal对象，连[Authorize]特性的第一道认证关卡都无法通过，用户完全没有篡改声明内容的可能。
需要注意的是，文档中“ID Token不可用于授权”的描述，特指不能将ID Token作为凭据发送给下游第三方API做授权验证，并非禁止在当前应用自身的访问控制逻辑中使用ID Token内的声明。你当前的单体MVC应用使用ID Token声明做内部访问管控，完全在官方划定的合法使用范围内。
这个方案唯一的局限性是存在权限更新缓存窗口：ID Token默认有效期为1小时，如果你在B2C中修改了用户的extension_TeamId属性，已经签发的旧Token在过期前不会自动更新，会出现最长1小时的权限不一致。

2. 本地数据库存储用户-团队关联方案的合规性 #

这个方案不存在“更合规”的说法，属于纯业务选型，两种实现都符合微软身份平台的使用规范，按需选择即可：

• 如果你没有额外的团队关联业务逻辑，TeamId的唯一数据源就是B2C的自定义属性，也能接受最长1小时的权限更新延迟，直接读取extension_TeamId声明完全可行，还能省去一次数据库查询，性能更好。
• 如果你需要存储更多团队关联的业务属性（比如团队内角色、细粒度操作权限、加入时间等），或者要求团队归属变更后立刻生效，那么使用B2C返回的用户对象ID（Guid类型，对应声明oid）作为主键查询本地用户-团队关联表是更合适的选择，数据一致性更强，后续业务扩展也更方便。

核心安全准则只有一条：永远不要信任前端提交的任何身份、权限相关参数，所有权限判断的数据源要么是经过中间件校验后生成的ClaimsPrincipal中的声明，要么是服务端数据库存储的可信数据。

3. 当前场景下的令牌类型明确 #

你这个不调用下游API的单体MVC场景，后端根本不会用到Access Token，整个登录流程中只有ID Token是颁发给你当前应用的。
标准OIDC登录流程下，用户跳转到B2C完成认证后，B2C会通过回调请求把ID Token直接发送到你的后端接口，Microsoft.Identity.Web中间件校验完ID Token合法性之后，会把解析出的用户身份、声明加密序列化到认证Cookie里。后续用户访问所有受[Authorize]保护的接口/页面时，请求携带的是这个加密的认证Cookie，不是裸的JWT令牌，后端直接从Cookie解密后的身份信息中构建ClaimsPrincipal，不存在前端向后端传递裸Token的环节。
两者的适用边界可以明确为：

• ID Token的受众是你当前注册的MVC应用本身，唯一作用就是给当前应用用来识别用户身份、做应用内部的访问控制，完全匹配你的场景。
• Access Token的受众是你要调用的下游受保护资源（比如Graph API、独立部署的其他后端API服务），只有当你的应用需要代表用户调用这些外部资源时，才需要向B2C申请签发Access Token，你当前的单体应用场景完全不需要用到Access Token。

内容的提问来源于stack exchange，提问作者Dan Harris