为何OIDC授权码流无法全程采用后端通道？

为什么授权码流不能全程采用后端通道？ #

核心原因是用户身份认证必须由用户直接与身份提供商（IdP）完成交互，这是OIDC的核心设计逻辑：

• IdP需要验证操作主体是真实用户，比如展示登录页面、处理多因素认证（MFA）、获取用户授权同意等，这些步骤必须用户亲自参与，后端无法替代用户完成身份验证和授权确认。
• 如果全程走后端通道，后端无法将IdP的登录界面呈现给用户，也无法获取用户输入的凭证或授权意愿，直接跳过了用户身份验证的关键环节，违背了OAuth2/OIDC的安全设计初衷——确保用户主动授权第三方应用访问其资源。

是否可以由前端传递参数给后端，再由后端向IdP请求令牌？ #

这种方式是可行的，但需要注意几个核心细节：

• 前端到后端的参数传递：前端可以将scope、redirect_uri等必要参数传给自身后端，由后端组装授权请求并发起。但这里的第一步（获取授权码的请求）仍然需要将用户重定向到IdP的登录页面，因为IdP必须与用户直接交互完成认证和授权。
• 授权码的回调与令牌交换：用户在IdP完成认证授权后，IdP会将授权码回调到后端配置的redirect_uri（而非前端），后端再携带授权码、客户端ID、客户端密钥向IdP请求交换access token和id token。
• 令牌的分发与使用：后端拿到令牌后，可以将id token返回给前端用于用户身份标识，access token则建议由后端保存，后续后端服务间调用时直接携带即可，避免令牌暴露在前端带来的安全风险。

本质上这种方式是授权码流的变种，只是把前端发起授权请求的环节转移到了后端，但核心的用户与IdP交互环节仍然无法省略。

内容的提问来源于stack exchange，提问作者David Klempfner