面经策

OAuth 2.0 的四种授权模式是什么？前后端分离的 API 场景选哪种？ ​

  • 标签：Spring Security、认证授权、后端

🏛 业务架构师 ​

OAuth 2.0 的四种授权模式（Grant Types），按业务适用性讲：

  1. 授权码模式（Authorization Code）：用户跳转授权服务器登录并同意 → 回调给客户端授权码 → 客户端拿码换 Token。适合：有后端的 Web 应用、第三方登录（"用微信登录"）——最安全最主流；
  2. 客户端凭证模式（Client Credentials）：客户端用自己的身份（client_id/secret）直接换 Token，无用户参与。适合：服务间调用（微服务 M2M、定时任务调 API）——机器对机器的标准答案；
  3. 密码模式（Resource Owner Password Credentials）：客户端收集用户名密码直接换 Token——OAuth 2.1 已废弃（客户端接触用户原始密码，违背 OAuth 初衷），存量系统尽快迁移；
  4. 隐式模式（Implicit）：授权服务器直接在回调 URL 里返回 Token（省去换码步骤）——历史上给纯前端浏览器用，因 Token 暴露在 URL、无刷新令牌，OAuth 2.1 已废弃，被"授权码+PKCE"取代。

前后端分离的 API 场景选哪种——这是实操重点：

  • 第一选择：授权码模式 + PKCE。用户在认证服务器页面登录（前端不碰密码），后端拿码换 Token；前端应用（SPA/小程序/App）必须加 PKCE 防授权码截获——OAuth 2.1 已强制公共客户端使用 PKCE；
  • 自有账号体系且信任度高的 App（第一方客户端）：也可用"手机号验证码/自有登录接口 + 自签发 JWT"的简化方案，不必硬套 OAuth——OAuth 解决的是"第三方委托授权"，第一方登录用 OIDC（授权码模式）或自建 Token 皆可；
  • 纯后端服务间互调：Client Credentials。

一句话：面向用户选"授权码+PKCE"，面向服务选"客户端凭证"，另两个模式是历史遗产——新项目不碰。

🏗 系统架构师 ​

OAuth 2.0 的四种授权模式（Grant Types）：

  • 授权码模式（Authorization Code）：用户跳转授权服务器登录授权 → 回调带 code → 后端用 code + client_secret 换 token。最安全、最通用（secret 只在服务端交换；可加 PKCE）；
  • 隐式模式（Implicit）：授权服务器直接在回调 URL 里放 access_token（跳过 code 交换）——纯前端 SPA 时代的历史产物，令牌暴露在 URL（浏览器历史/Referer 泄露），OAuth 2.1 已废弃；
  • 密码模式（Resource Owner Password Credentials）：应用直接收用户名密码换 token——要求极度信任应用（应用能碰用户原始凭据），官方 SPA/移动端禁用，仅遗留可信第一方脚本场景；
  • 客户端凭证模式（Client Credentials）：client_id/secret 直接换 token，无用户参与——服务间通信（M2M）标准：后端 A 调后端 B，身份是应用不是用户。

前后端分离的 API 场景选哪种？授权码 + PKCE（Authorization Code with PKCE）——2026 的唯一正确答案：

  • SPA/移动端存不住 client_secret（反编译/前端可见）——PKCE 用动态 code_verifier/code_challenge 替代 secret：每次授权随机生成 verifier，SHA256 后作 challenge 发起，换 token 时出示 verifier 证明"发起者=兑换者"——防授权码拦截攻击（中间人拿到 code 也换不出 token）；
  • 现代形态：OIDC + 授权码 + PKCE，令牌走后端通道（BFF 模式：前端只跟自家 BFF 会话，BFF 持 token 调 API）——令牌不进浏览器是安全加固的推荐架构；
  • 服务间（网关到微服务）另配 Client Credentials。

一句话：有用户参与 → 授权码 + PKCE；无用户（M2M）→ 客户端凭证；隐式与密码模式只在遗留系统考古时出现。

💻 全栈开发专家 ​

OAuth 2.0 四种授权模式（RFC 6749）：

  1. 授权码模式（Authorization Code）：用户跳转授权服务器登录 → 返回 code → 后端用 code+密钥换 token。最安全最主流（凭证不经过前端；配 PKCE 后是全场景标准）；
  2. 隐式模式（Implicit）：授权服务器直接在 URL fragment 返回 token——历史遗留（纯前端 SPA 时代），已废弃（token 暴露在 URL/浏览器历史，OAuth 2.1 已删除）；
  3. **密码模式（Resource Owner Password Credentials）：客户端直接拿用户账密换 token——要求用户绝对信任客户端，OAuth 2.1 已移除，仅遗留系统在用；
  4. 客户端凭证模式（Client Credentials）：客户端自己的身份换 token（无用户参与）——服务间调用（M2M）的标准。

前后端分离 API 场景选哪种？授权码 + PKCE：

浏览器 → 授权服务器 /authorize?client_id&redirect_uri
        &response_type=code&state=xxx
        &code_challenge=SHA256(verifier)   ← PKCE
用户登录授权 → 302 回 redirect_uri?code&state
前端拿 code → 后端 /token（code + code_verifier + client_secret 可选）
后端返回 access_token / refresh_token → 调 API

选它的理由：用户凭证只进授权服务器（第三方拿不到账密）；code 一次性且短命；PKCE 防 code 拦截（public client 没有 secret 的防护）；OIDC 在其上加 id_token 就是完整登录方案（第三方登录「用微信登录」全是这套）。

配套：自己全栈的「登录」不需要 OAuth2 授权码（自己的前后端直接发 JWT 即可）——OAuth2 解决的是委托授权（让第三方以受控方式访问资源），别把它当登录协议用，登录请上 OIDC。