ASP.NET 6 API迁移至Azure Docker+K8s后JWT多实例认证问题咨询

1. 多Docker实例运行时如何保障认证正常？ #

JWT本身是无状态的，核心要保证所有实例的JWT验证规则完全一致：

• 统一签名密钥/证书：绝对不能在代码里硬编码密钥，建议将密钥存储在Azure Key Vault中，让所有K8s Pod通过Azure AD服务身份访问Key Vault获取密钥；如果使用证书，同样将证书托管在Key Vault，容器通过挂载方式读取。
• 同步验证配置：Issuer（签发方）、Audience（受众）、过期时间等验证参数，要在所有实例中保持一致。可以将这些配置放在Azure App Configuration或K8s ConfigMap/Secret中，确保所有容器加载相同的配置。
• 一致的中间件配置：所有实例的AddJwtBearer中间件配置必须完全相同，包括签名算法、验证逻辑等，避免因配置差异导致验证失败。

2. 认证Cookie在多实例间能否正常工作？ #

默认情况下不行，但可以通过共享Data Protection密钥解决：

• ASP.NET的认证Cookie是用Data Protection服务加密的，单实例时默认使用本地机器密钥，多实例间密钥不同会导致跨实例无法解密Cookie。
• 解决方法是将Data Protection的密钥环存储在共享位置，比如Azure Blob Storage或Azure Redis，让所有实例共用同一套密钥。配置示例（Program.cs）：

builder.Services.AddDataProtection()
    .PersistKeysToAzureBlobStorage(new Uri("https://yourstorageaccount.blob.core.windows.net/keys/key.xml"))
    .SetApplicationName("YourApiAppName");

• 注意：纯API场景通常用Bearer Token（JWT）而非Cookie认证，如果你的API只是用JWT，其实不需要关注Cookie问题；只有当同时启用了Cookie认证时才需要处理。

3. 是否需要更换非JWT的认证方式？ #

不需要。JWT天生适配分布式、无状态的架构，完全满足K8s水平扩展的需求。只要做好上述的密钥共享和配置一致性，JWT在多实例环境下的可靠性和性能都有保障。除非你的业务有特殊需求（比如强依赖会话同步、需要实时注销JWT令牌等），否则没必要更换认证方式。

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