NGINX+Identity4环境下IIS中.NET Framework站点JWT验证异常求助

下面是NGINX、Ingress与IIS交互时触发问题的关键因素：

1. 代理头传递不完整，OWIN无法识别真实请求上下文 #

.NET Framework的OWIN认证中间件不会自动处理代理头，而.NET Core的ASP.NET Core默认通过ForwardedHeadersMiddleware适配反向代理。如果NGINX/Ingress没正确传递以下头，直接导致认证逻辑混乱：

• X-Forwarded-Proto：IIS端会认为请求是HTTP，但Identity4返回的回调地址是HTTPS，回调URL校验失败，触发循环跳转。
• X-Forwarded-Host：Ingress修改主机头后，IIS应用无法获取真实域名，生成的认证请求地址和Identity4配置的回调地址不匹配，令牌验证直接失败。
• X-Forwarded-For：部分场景下会影响IP相关的校验逻辑，间接导致认证异常。

2. IIS自身的重写/ARR配置和NGINX叠加冲突 #

如果IIS上配置了URL重写或ARR反向代理，和NGINX的代理逻辑叠加后会出现：

• 请求URL被多次改写，Identity4签发的JWT中iss/aud字段和IIS端验证逻辑不匹配，令牌验证失败。
• ARR未启用“转发主机头”，OWIN无法解析正确请求路径，回调时路径不匹配，引发认证循环。

3. OWIN中间件缺少代理感知配置 #

OWIN的OpenIdConnectAuthenticationMiddleware默认没有代理适配能力，必须手动配置：

• 显式设置RedirectUri为外部可访问的完整URL（不能用相对路径或IIS内部地址）。
• 启用UseTokenLifetime并确认令牌有效期配置，避免因令牌过期过快触发重复认证。
• 手动添加中间件处理X-Forwarded-Proto，强制将请求Scheme设置为HTTPS，比如通过Microsoft.Owin.Host.SystemWeb的ForwardedHeadersOptions。

4. SSL终止后的Cookie属性不兼容 #

NGINX在Ingress层做SSL终止后，传给IIS的是HTTP请求，但OWIN生成的认证Cookie默认开启Secure属性：

• 浏览器会拒绝保存HTTP请求下的Secure Cookie，导致每次请求都无认证状态，触发循环跳转。
• 对比.NET Core：ASP.NET Core的Cookie中间件会根据代理头自动调整Cookie属性，而OWIN需要手动设置CookieSecure = CookieSecureOption.SameAsRequest来适配。

5. Ingress路径重写导致请求上下文丢失 #

如果Ingress配置了路径重写（比如/app/*重写为/*），NGINX传给IIS的路径和外部访问路径不一致：

• Identity4配置的回调URL是https://example.com/app/signin-oidc，但IIS收到的是/signin-oidc，回调校验失败后触发重新认证循环。
• .NET Core可通过PathBase配置适配，而OWIN需要手动设置Request.PathBase匹配Ingress的重写规则。

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