授权码登录，密码登录，客户端凭证登录，我前年做过，都忘了

太正常了，这些模式就像“黑话”，一段时间不用确实容易记混。既然你前年实操过，我们不讲虚的，直接用**“谁在登录”和“怎么拿令牌”**这两条线，帮你瞬间找回记忆。

在 OAuth 2.0 中，这叫 Grant Types（授权类型）。

1. 授权码模式 (Authorization Code) —— 最标准、最安全

这是你最常在“微信登录/GitHub 登录”中看到的流程。

• 适用场景： 有后端的 Web 应用。

• 核心逻辑： 令牌（Token）不直接给浏览器，而是通过服务器后端交换，防止泄露。

• 找回记忆：

  1. 用户点“登录”，跳到认证服务器。

  2. 用户输入账号密码，认证服务器给浏览器一个临时授权码 (Code)。

  3. 浏览器带着 Code 回到你的服务器，你的后端拿着 Code + AppSecret 去认证服务器换真正的 Access Token。

  一句话记忆： 它是“两步走”，中间加了个 Code 做中转，为了安全。

2. 密码模式 (Resource Owner Password Credentials) —— 最直接

• 适用场景： 高度信任的应用（比如你自家的 App 登录自家的后端）。

• 核心逻辑： 用户直接把账号密码输给你的应用，你直接拿着账号密码去换 Token。

• 找回记忆：

  • 这就是最传统的表单登录。

  • 因为应用能拿到用户的原始密码，所以 安全性最低，第三方应用严禁使用。

  一句话记忆： 把密码直接交给应用去换钱（Token），必须是“亲儿子”应用才敢这么干。

3. 客户端凭证模式 (Client Credentials) —— 机器对机器

• 适用场景： 没有“人”参与的场景。比如微服务之间调用、定时任务拉取数据。

• 核心逻辑： 只有 AppID 和 AppSecret，没有用户账号密码。

• 找回记忆：

  • 比如你的订单中心要调用库存中心的接口，它不需要代表某个用户，它代表的是“订单中心”这个系统。

  • 直接传 client_id 和 client_secret 拿 Token。

  一句话记忆： 两个服务器之间“对暗号”，跟具体哪个用户登录没关系。

快速对比表

还有一个你可能忘了的：刷新令牌 (Refresh Token)

当时你可能还处理过 Token 过期的问题。

• Access Token 通常很短（如 2 小时），为了安全。

• Refresh Token 通常很长（如 7 天）。

• 操作： 当 Access Token 报 401 了，后端悄悄用 Refresh Token 去换个新的 Access Token，用户就不用重新登录了。

现在的你，是不是感觉那段代码逻辑正在脑子里重组？ 当时你做的时候，是用 Spring Security 还是手动写的拦截器？