OAuth2授权码流程：为何需重定向至认证服务登录而非本地页面调API

• 核心安全考量：避免凭证泄露
  前端JavaScript应用运行在浏览器环境中，代码完全暴露给用户，不存在真正的“安全存储”。如果在前端嵌入登录页面，用户输入的用户名/密码会通过前端发送到认证服务——哪怕用HTTPS加密，一旦页面存在XSS漏洞，攻击者就能窃取这些敏感凭证。而重定向到认证服务的登录页后，用户的凭证直接在认证服务的域名下输入和提交，完全不经过前端应用，从根源上避免了前端层面的凭证泄露风险。

• 防止钓鱼攻击，保障用户信任
  授权码流程的核心是「用户明确授权」。重定向到认证服务的官方登录页，用户能通过域名、页面样式等确认自己正在和信任的认证系统交互，而非伪造的前端页面。如果前端嵌入登录表单，攻击者很容易仿造相同的页面样式钓鱼，让用户误以为是官方登录，进而泄露凭证。

• 集中化认证管理，降低风险
  认证服务负责统一处理身份验证逻辑：比如多因素认证（MFA）、密码复杂度校验、会话过期控制、异常登录检测等。这些逻辑放在服务端能确保所有接入的应用（包括你的JS应用和后端服务）遵循一致的安全标准，同时避免前端重复实现认证逻辑带来的漏洞。如果前端嵌入登录页，相当于把部分认证逻辑分散到前端，不仅维护成本高，还容易因前端实现疏漏引入安全问题。

• 符合授权码流程的设计初衷
  授权码流程的设计目标是分离用户身份验证和应用授权，前端应用本身不应该接触用户的核心凭证。如果用前端调用API登录的方式，本质上是在使用OAuth2的「资源所有者密码凭证模式」——这种模式仅适用于高度信任的应用，绝对不推荐给前端公开应用，因为前端无法安全保存客户端密钥，也无法避免密码被窃取的风险。

内容的提问来源于stack exchange，提问作者Kamil Kos