OAuth2.0 授权码模式在 API 鉴权安全性上显著优于密码模式，适用于绝大多数第三方 Web 应用和公网场景。密码模式因客户端需直接处理用户凭证，存在凭据泄露风险，仅建议在高度信任的第一方应用或遗留系统迁移中使用。
先说结论：授权码模式通过服务端交换令牌避免凭据暴露，是 OAuth2.0 标准推荐的安全方案，密码模式应视为高风险遗留方案。
- 适合：授权码模式适合有后端的 Web 应用及第三方接入，密码模式仅限高度信任的第一方应用。
- 重点看：授权码模式重点看服务端 Code 换 Token 流程，密码模式重点看客户端凭证存储风险。
- 别忽略：授权码模式需校验 Redirect URI，密码模式需警惕客户端窃取用户密码的可能性。
快速处理思路
若正在设计新系统，直接选择授权码模式（Authorization Code Grant），避免后续安全整改成本。若维护旧系统使用密码模式，需评估客户端可信度，并计划迁移至授权码模式或客户端凭证模式。对于纯前端应用，避免使用密码模式，应考虑授权码模式配合 PKCE 或客户端凭证模式。
为什么会这样
授权码模式的安全性核心在于用户密码不经过客户端。在授权码模式中，用户直接在授权服务器输入密码，客户端仅获取临时授权码，再用客户端密钥在服务端交换令牌，密码从未暴露给客户端。相比之下，密码模式要求用户将账号密码直接交给客户端，客户端持密码向授权服务器请求令牌，一旦客户端被攻破或恶意操作，用户凭证即泄露。
分步处理
第一步：评估客户端类型与信任等级。若为第三方应用或公网 Web 应用，必须使用授权码模式；若为自家内部高度信任应用，可暂时保留密码模式但需限制权限。
第二步：配置授权服务器回调地址。在授权码模式下，严格绑定 redirect_uri，确保授权码只能回传到预设的安全后端地址，防止授权码被劫持。
第三步：实施服务端令牌交换。客户端后端收到授权码后，携带 client_id 和 client_secret 向授权服务器请求 Access Token，确保 client_secret 不泄露给前端浏览器。
第四步：设置令牌有效期与刷新机制。授权码模式支持 Refresh Token，可设置较短的 Access Token 有效期，通过刷新令牌维持会话，减少令牌泄露后的影响范围。
怎么验证是否生效
检查网络请求日志，确认用户登录请求是否直接发往授权服务器而非客户端后端。在授权码模式下，浏览器地址栏不应出现用户密码参数，且 Access Token 不应通过 URL 参数传递。查看客户端代码，确认 client_secret 仅存储在后端环境变量或配置中心，未硬编码在前端资源中。监控授权服务器日志，验证是否存在异常的密码模式令牌请求来源。
常见坑
在移动端原生应用中误用密码模式，导致密码存储在本地明文文件中。授权码模式下未校验 state 参数，可能遭受跨站请求伪造攻击。将 Access Token 直接存储在 localStorage 中，易受 XSS 攻击窃取，建议使用 httpOnly Cookie 存储。密码模式在公共客户端（如单页应用）中使用，导致 client_secret 暴露。
常见问题
移动端 App 应该用哪种模式？
移动端 App 推荐使用授权码模式配合 PKCE（Proof Key for Code Exchange），避免使用密码模式以防止密码泄露。
密码模式是否被官方废弃？
公开资料中没有看到可靠的量化数据表明官方完全废弃，但多数安全指南建议逐渐弃用，仅用于遗留系统集成。
授权码模式流程太复杂怎么办？
可使用成熟的 OAuth2 客户端库处理流程细节，重点确保后端正确实现 Code 换 Token 逻辑，不要自行简化流程。
参考来源
OAuth2 授权码模式与密码模式的安全机制及选型对比（2026 年 6 月 3 日）
OAuth 2.0 四种授权方式小结（2026 年 6 月 17 日）
OAuth 2.0 的授权码模式 (Authorization Code Grant) 的工作流程是怎样的？（2025 年 11 月 5 日）
Oauth2.0 四种授权模式：适用场景、流程与个人思考（2024 年 1 月 17 日）
Go 语言实现 OAuth2.0:3 种主流流程对比与最佳实践推荐（2025 年 10 月 24 日）