OAuth 2.0授权流程经常跨越浏览器和服务器。用户在浏览器完成登录与同意后，应用后端还要访问Token端点，用授权码换取Token。浏览器能够打开授权页，并不能证明应用容器的DNS、正向代理、CA和客户端认证配置正确。
授权码流程的两条链路
| 链路 | 请求方 | 重点检查 |
|---|---|---|
| 授权端点 | 用户浏览器 | 反向代理、回调URI、state与Cookie |
| Token端点 | 应用服务器 | 正向代理、客户端认证、TLS与超时 |
| 资源API | 应用或客户端 | Access Token、受众、权限与重试 |
| 刷新端点 | 应用服务器 | Refresh Token保护与轮换 |
Token请求为何常在服务器失败
应用部署在容器、私网或Serverless环境，可能无法使用开发者电脑的系统代理。Token主机还可能与授权页面不同，企业代理需要允许CONNECT和正确证书。应从应用实际网络发送最小测试，不要把Client Secret放进curl历史。
客户端认证有哪些形式
机密客户端可使用HTTP Basic、请求体Secret、私钥JWT或mTLS等机制，具体由提供方支持。认证方式配置错会返回invalid_client。公共客户端通常不应持有Client Secret，而使用PKCE保护授权码。
PKCE为什么不能被代理替代
PKCE让客户端生成Verifier并发送Challenge，换Token时证明是原发起者。代理只负责网络路径，不提供该证明。Verifier丢失、多实例会话不一致或回调被错误路由，会导致invalid_grant。
授权码超时后重试为何复杂
授权码通常短时有效且只能使用一次。Token响应在网络中丢失时，服务端可能已经消费授权码。客户端再次提交会得到invalid_grant。应用应把流程状态与请求ID关联，必要时重新发起授权，而不是无限重试。
刷新令牌轮换怎样处理
部分提供方每次刷新都会返回新Refresh Token并使旧值失效。并发刷新若没有锁或版本控制，会让一个进程覆盖另一个新Token。应对账号或会话串行刷新，原子保存新值，并按提供方规则处理重用检测。
代理状态与OAuth错误分层
- 407：正向代理凭据；
- invalid_client：客户端认证失败；
- invalid_grant：授权码、刷新令牌、PKCE或时间问题；
- invalid_scope：请求范围不被允许；
- 401/403：资源API Token、受众或权限；
- TLS错误：CA、域名、系统时间或代理检查。
时间偏差为何影响令牌
JWT的iat、nbf和exp依赖时间，私钥JWT客户端认证也有短有效期。服务器时钟偏差会导致刚签发Token被判未生效或已过期。应使用可靠时间同步，不能通过扩大容忍到不合理范围解决。
令牌不能出现在哪里
Access Token、Refresh Token、授权码和Client Secret不应出现在URL、反向代理日志、Trace属性、错误页和工单。日志只记录流程ID、Token端点、错误代码、HTTP状态和脱敏客户端标识。
代理连接池会影响刷新吗
应用HTTP客户端可能长期复用代理连接。代理地址、证书或凭据轮换后，旧池仍可能失败或走旧出口。应使用新客户端池有序切换，避免所有刷新请求同时失败。
排查顺序
- 记录Grant类型、客户端类型和端点；
- 区分浏览器授权与服务器Token请求；
- 检查应用环境代理、DNS、CA和时间；
- 确认客户端认证与PKCE状态；
- 区分407、invalid_client与invalid_grant；
- 模拟响应丢失和并发刷新；
- 清理日志中的所有令牌与Secret。
延伸阅读
涉及反向代理外部URL和回调Cookie时，可结合OIDC回调、Issuer与可信头排查。
结论
OAuth 2.0代理问题不能只看登录页面。Token交换、资源API和刷新是服务器侧独立链路，必须同时处理客户端认证、PKCE、时间、令牌轮换与安全重试。
