.NET 5 Web API对接AD/SSO客户端时如何实现JWT请求认证

你现有已实现的JWT认证链路不需要整体推翻重构，核心调整点只有JWT颁发逻辑：原逻辑要求客户端传递账号密码校验后发令牌，现在改为信任客户端侧已经完成的AD/SSO认证结果，校验身份合法后再颁发系统JWT即可，后续业务接口的JWT校验、角色/策略授权逻辑完全可以复用现有代码，不需要改动。

针对目前暂未完全确认的客户端认证方案，可按两种最常见的企业内对接场景提前做兼容：

场景1：客户端采用Windows AD域集成认证 #

• 若API部署在IIS上，直接在IIS功能配置中开启Windows认证、关闭匿名认证；若采用Kestrel部署，先引入Microsoft.AspNetCore.Authentication.Negotiate包，在服务注册阶段同时添加Negotiate认证方案和原有JWT认证方案，支持两种认证方式并存。
• 单独开放一个供域内客户端调用的JWT颁发接口，该接口不需要接收账号密码：请求进入后先通过Negotiate认证获取请求携带的Windows域账号信息（从HttpContext.User.Identity.Name读取域账号名），匹配本地系统权限表校验该账号是否有接口访问资格、对应绑定的角色/权限范围，校验通过后按原有逻辑生成带权限声明的JWT返回给客户端。
• 客户端侧调用该颁发接口时，只需要在请求配置中设置使用当前登录用户的Windows默认凭据，不需要手动输入账号密码；拿到JWT后，后续所有业务接口调用都按原有规则在Authorization头携带JWT即可。
• 前置要求：API服务所在服务器和客户端机器需在同一个AD域，或所在域存在双向信任关系，否则无法正常读取域身份信息。

场景2：客户端采用公司统一SSO认证（OAuth2/OIDC协议，含Azure AD、企业自研SSO等） #

• 这类场景下客户端已经提前从统一SSO服务拿到了用户的身份令牌（ID Token/Access Token），不需要用户在你的系统重复输入密码，你只需要做SSO令牌的可信校验即可。
• 调整Auth控制器逻辑，新增一个接收SSO令牌的JWT颁发入口：按照公司SSO提供的签名公钥、合法颁发者、受众范围规则，校验客户端传入的SSO令牌是否合法、是否在有效期内，从验签通过的令牌中解析出用户唯一标识（工号/域UPN等），匹配本地权限映射表确认用户访问权限后，颁发自有系统的JWT。
• 若不想做二次颁发JWT的逻辑，也可以直接在API认证中间件中增加SSO令牌的校验规则，直接认可验签通过的SSO令牌请求为已认证请求，补做本地权限映射即可。但更推荐保留自有JWT层做解耦，后续不管对接什么身份源，业务接口的授权逻辑都不需要调整。

• 所有身份凭据必须经过服务端验签/可信校验，禁止直接信任客户端明文传递的用户ID、角色信息，避免身份伪造、越权访问。
• 本地单独维护域账号/SSO用户标识和系统内角色、权限的映射关系，不要直接复用AD组、SSO内置角色做权限判断，避免跨系统权限边界混乱。
• 给对接客户端颁发的JWT要设置合理的过期时间，可配合刷新令牌机制降低令牌泄露的风险。
• 如果客户端是无用户交互的服务端调用场景，可额外叠加客户端证书、长期API Key做客户端身份校验，和用户身份认证逻辑拆分：先校验客户端本身的调用白名单权限，再关联对应操作人身份留痕。

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