代理/重定向OIDC .well-known端点共享服务器地址是否合理？有无相关标准？

方案是否可行？ #

完全可行。

OIDC协议的核心依赖之一就是/.well-known/openid-configuration发现端点——SPA和API通过请求这个端点，就能自动获取OIDC服务器的所有关键配置（授权端点、令牌端点、公钥地址等）。只要你部署一个固定的代理/重定向服务指向这个端点，所有应用和API只需要配置这个固定的代理地址即可，后续OIDC服务器变更时，只需要更新代理/重定向的目标地址，无需逐个修改应用和API的配置。

实践中需要注意几个细节：

• 若用重定向：需使用标准的HTTP 301或302状态码，同时要确保你的SPA和API的HTTP客户端支持跟随重定向（绝大多数现代HTTP客户端默认支持，但要确认老旧或自定义客户端的配置）。
• 若用反向代理：要保证返回的配置内容与原OIDC服务器的完全一致——如果原服务器返回的是绝对URL（比如https://actual-oidc-server.com/auth），直接透传即可；如果是相对URL，要确保代理的上下文路径不会导致客户端解析错误。
• 缓存策略：原OIDC服务器的发现端点通常会带有Cache-Control等缓存头，代理时建议保留这些头部，平衡性能与配置更新的时效性，避免频繁请求原服务器的同时，能及时获取变更后的配置。

是否有相关标准或RFC？ #

有两个核心RFC作为依据：

• RFC 8414（OpenID Connect Discovery 1.0）：该标准明确了OIDC发现机制的规范，包括/.well-known/openid-configuration端点的定义和作用。标准并未禁止对该端点进行代理或重定向，只要客户端能通过该端点获取到合法有效的OIDC配置，就符合协议要求。
• RFC 5785（Defining Well-Known Uniform Resource Identifiers (URIs)）：这是.well-known路径的基础规范，允许服务端对这类路径实施代理或重定向操作，只要遵循HTTP协议的重定向规则即可。

实践建议 #

• 优先选择反向代理：相比重定向，反向代理对客户端完全透明，不需要客户端处理任何重定向逻辑，能降低潜在的兼容性问题。
• 配置验证：代理上线后，务必验证返回的配置内容，重点检查授权端点、令牌端点等核心URL是否指向正确的OIDC服务器，避免因配置错误导致认证失败。
• 监控与告警：给代理端点添加监控，跟踪可用性和返回内容的正确性，当原OIDC服务器变更后，确保代理能及时同步新配置，避免应用出现认证中断。

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