IdentityServer4部署Azure后客户端/signin-oidc登录报500令牌解析错误

本地调试全流程跑通，部署到Azure才触发的异常，核心是本地开发环境和Azure反向代理托管环境的配置、持久化机制差异，代码逻辑本身没有硬伤，按照下面的顺序逐点排查即可快速定位：

1. 优先定位IdentityServer服务端的500根因 #

客户端抛出的“无法解析text/plain响应为JSON”只是表象，真正的错误发生在IS4的/connect/token令牌端点，不要上来就改客户端配置：

• 第一步先开启IS4的生产环境详细错误输出：在IS4服务的appsettings.Production.json中添加配置"IdentityServer": { "DetailedErrors": true }，调整日志级别让IdentityServer类别的日志输出Debug级别，通过Azure应用服务的日志流直接抓取/connect/token请求的报错堆栈，这是最直接的定位方式，不用盲猜。
• 排查IS4的签名密钥持久化配置：这是IS4部署到Azure最高发的坑。很多人图省事在生产环境留了AddDeveloperSigningCredential()，这个方法在本地调试时会把签名密钥存在本地磁盘的固定路径，重启不会丢；但部署到Azure后，应用运行在沙箱环境，默认的密钥存储路径是临时目录，每次应用重启都会被清空，重新生成新的密钥材料。当客户端拿授权码换令牌时，IS4找不到之前签发授权码对应的密钥，就会直接返回不带JSON格式的500通用错误页。生产环境绝对不要用开发者模式的临时签名凭证，需要把签名证书存在Azure Key Vault或者App Service的/home持久化目录，通过代码加载固定的持久化签名凭证。
• 排查Azure反向代理的转发头与公开源配置：Azure App Service是反向代理架构，默认IS4无法感知自己对外的公开HTTPS地址，会把内部的HTTP回环地址当成自己的服务地址，导致生成的回调链接、令牌校验逻辑出错，直接抛500。需要在IS4服务的Startup管道中，在app.UseIdentityServer()之前添加转发头配置，处理X-Forwarded-For和X-Forwarded-Proto头，同时在配置文件中明确指定PublicOrigin为IS4在Azure的对外HTTPS地址，不要让IS4自行推断公开地址。
• 校验客户端实体配置的精确匹配：确认IS4中注册的客户端配置里，RedirectUris、PostLogoutRedirectUris是精确匹配客户端部署到Azure后的HTTPS地址，没有残留本地调试的localhost地址、没有用http协议、没有带错误的端口号；同时检查IS4所在的App Service有没有开启自带的Easy Auth/认证功能，这个功能会拦截所有请求的身份校验流程，和IS4的流程冲突，直接返回纯文本的认证错误页。

2. 排除客户端侧的配置偏差 #

等服务端的500错误排除后，再校验客户端的配置是否适配Azure托管环境：

• 检查客户端配置的Authority地址是否为IS4的Azure对外HTTPS地址，没有写错成http协议、没有残留本地调试的localhost地址。IS4默认会拦截所有走HTTP的令牌请求，直接返回纯文本的安全策略错误，不会返回标准的OAuth JSON错误格式，刚好匹配异常描述的响应特征。
• 校验客户端秘钥的一致性：确认客户端在OIDC配置中传入的ClientSecret，和IS4中注册的客户端秘钥完全一致，没有因为部署环境差异出现秘钥加密、读取错误的问题。秘钥校验不通过时，IS4同样会返回纯文本的错误响应。
• 检查App Service的WAF规则拦截：如果两个应用所在的App Service开启了Web应用防火墙，要确认WAF没有拦截带code、state参数的OIDC回调请求，以及/connect/token的POST请求，WAF拦截的响应一般是纯文本的规则提示，同样无法被客户端解析为JSON格式。

3. 快速取响应内容的临时调试方法 #

不用逐行猜问题，临时修改客户端的OIDC事件配置，在OnRemoteFailure事件中拦截原始的响应内容，把服务端返回的纯文本直接写入日志：

捕获远程验证失败事件时，不要直接抛出协议异常，先读取请求响应的原始文本，这里面一般会直接标注500的具体原因，比如签名密钥缺失、重定向地址不匹配、公开源配置错误，拿到具体错误文本后可以直接对应到具体配置项调整。

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