离线C# Web API通过客户端获取公钥实现JWT授权的可行性咨询

核心结论：不建议让客户端传递公钥到离线API #

你的方案存在多个关键问题，具体如下：

1. 严重的安全隐患 #

• 请求头属于客户端可控内容，恶意用户可篡改请求头中的公钥，传入伪造公钥后，API会用假公钥验证伪造的JWT，直接绕过授权机制。
• 即便客户端可信，公钥在传输过程中也可能被中间人替换，导致API验证无效签名，破坏整个授权链路的安全性。

2. 可用性与性能问题 #

• 客户端每次请求API都需先从Identity Server拉取JWKS，增加了客户端逻辑复杂度和请求延迟。
• 若Identity Server临时不可用，客户端无法获取公钥，哪怕API本身离线可用，也会导致服务中断，违背API离线部署的初衷。

3. 违背OIDC设计原则 #

OIDC规范中，JWT签名的验证责任属于依赖方（即你的Web API），要求依赖方主动从信任的Identity Server端点获取并缓存公钥，而非依赖客户端传递。这种设计是为了确保公钥来源的可信度，避免中间人攻击或客户端篡改。

更合理的离线授权替代方案 #

方案1：预缓存+定期更新JWKS #

• 在API部署前，从Identity Server的/.well-known/openid-configuration/jwks端点拉取公钥，存入API本地配置文件（如appsettings.json）或本地数据库。
• 若API偶尔能联网，配置JwtBearerOptions的缓存策略，让API定期联网更新公钥；若完全离线，后续Identity Server更换证书时，只需更新API配置包重新部署即可（无需分发敏感证书，比共享证书方案更灵活）。

方案2：使用包含证书链的JWT #

• 配置Identity Server，在签发JWT时将公钥证书链放入JWT的x5c字段（OIDC规范允许的字段）。
• API验证JWT时，直接从x5c字段提取公钥验证，无需依赖外部网络请求。此方案缺点是会增加JWT大小，但完全适配离线场景。

方案3：离线同步JWKS #

• 部署一台能同时访问Identity Server和API内网的中间机器，定期从Identity Server拉取最新JWKS，同步到API本地存储（如文件系统、内网数据库）。
• API验证时直接读取本地存储的公钥，无需联网，既保证公钥时效性，又适配离线环境。

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