Docker部署.NET Core 5服务时[Authorize]属性无法验证有效用户问题求解

问题根因判断 #

你的猜测不正确。你遇到的IDX10501报错属于JWT令牌签名校验阶段无法匹配对应kid的签名公钥，和Cookie共享没有直接关系：IIS同域下走Cookie认证的场景，和你当前容器部署后API网关的JWT校验逻辑属于两个完全独立的认证链路。

常见触发原因 #

• API网关配置的IdentityServer4（IS4）地址和IS4实际对外暴露的地址不一致：IS4的元数据端点/.well-known/openid-configuration返回的签名公钥地址，是基于IS4服务内部配置的Authority生成的。如果API网关配置的Authority是容器内部的服务名（比如http://auth-server:5000），但IS4本身配置的Authority是对外的域名/IP，或者反过来，就会导致网关拉取不到正确的公钥。
• IS4的签名密钥是临时生成的：默认开发环境下IS4会使用临时签名密钥，每次重启容器都会重新生成新kid的密钥，如果没有持久化签名密钥，重启IS4容器后旧令牌对应的kid就会失效。
• 网络隔离导致API网关无法访问IS4的元数据端点：Docker容器网络配置问题，网关容器无法请求到IS4的公钥获取接口，无法缓存对应kid的公钥。

修复方案 #

1. 统一Authority配置 #

• IS4服务端配置的Authority和API网关JWT校验配置的Authority必须完全一致：如果对外暴露用的是公网域名，两边都填公网域名；如果是容器内部通信，两边都填Docker DNS能解析的服务名+内部端口。
• 如果IS4部署在反向代理后面，需要配置IS4启用转发头：在IS4的Program/Startup中添加app.UseForwardedHeaders()，并且配置options.ForwardedHeaders = ForwardedHeaders.XForwardedProto | ForwardedHeaders.XForwardedHost，避免IS4生成元数据时用内部HTTP地址而不是外部HTTPS地址。

2. 持久化IS4签名密钥 #

生产环境不要用临时开发密钥，生成正式的RSA密钥或者X.509证书，挂载到IS4容器中持久化使用，示例代码：

// IS4服务端配置
var rsa = RSA.Create();
rsa.ImportFromPem(File.ReadAllText("/path/to/persisted/key.pem"));
builder.Services.AddIdentityServer()
    .AddSigningCredential(new RsaSecurityKey(rsa))
    // 其余业务配置

3. 验证公钥可达性 #

进入API网关容器内部，手动请求{配置的Authority}/.well-known/openid-configuration/jwks，确认能正常返回包含对应kid的公钥列表。

4. 补充：若你的网关确实走Cookie认证而非JWT才需要配置Cookie共享 #

• 所有服务配置Cookie的Domain为同一个父域，并且配置Cookie.SameSite = SameSiteMode.Lax，Cookie.SecurePolicy和你的访问协议匹配（HTTP用None，HTTPS用Always）。
• 所有服务配置统一的数据保护密钥，持久化到共享存储或者挂载的共享文件中，避免不同容器生成的加密密钥不同，无法解密其他服务生成的Cookie。

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