使用.Net Core Identity与OIDC对接多.NET Core Web API问题咨询

核心结论 #

你的开发思路没有偏差，该拆分方案完全可行，拆分后部署在不同服务器或AWS Lambda中的API，[Authorize]特性可以正常生效。

生效原理与配置要求 #

[Authorize]特性的校验逻辑完全依赖ASP.NET Core的认证中间件配置，和API的运行环境、部署位置没有关联，只要所有拆分的API项目满足以下两个核心配置要求即可正常工作：

• 所有API项目的JWT认证规则完全统一：不管是Azure AD OIDC颁发的JWT令牌，还是本地账号密码登录后自研签发的JWT令牌，所有独立API的JWT Bearer中间件必须配置相同的签发者（Issuer）、受众（Audience）、签名校验规则，确保每个API都能识别前端传入的令牌是否合法。
• 两种登录方式最终返回统一格式的JWT：本地账号密码的校验逻辑可以单独封装在公共认证API中，验证通过后和Azure AD登录流程一样，签发符合统一规则的JWT返回给前端，前端后续调用所有API时统一在Authorization请求头携带该令牌即可。

落地实践建议 #

• 把JWT认证配置、通用授权逻辑封装成独立的公共类库，所有拆分的API项目直接引用该类库，避免多项目重复配置出现规则不一致的问题。
• 如果需要用到基于角色、策略的细粒度授权，要么在签发JWT时把角色、权限声明统一写入令牌的Claims中，要么所有API共享同一个权限存储源，确保不同API对同一个用户的权限判断结果一致。
• 部署为AWS Lambda函数时不需要调整认证逻辑，ASP.NET Core的JWT认证中间件在Lambda运行环境中可以正常工作，只需要把签名密钥、Issuer、Audience这类敏感配置放到Lambda的环境变量中即可，不要硬编码在代码里。

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