我在日常开发里被问得最多的一个问题，就是“OAuth 2.0 到底是什么”。问的人从刚转行的前端到写了几年后端的都有，大家对这四个词的印象往往停留在“登录的时候弹个 GitHub 授权框”或者“拿 Token 调接口”，但真要解释清楚它解决了什么问题、授权码模式为什么是四个模式里的王牌，很多人是模糊的。
这很正常。OAuth 2.0 是个授权框架，不是一套具体的 API，也不是一个库，它定义的是“怎么把资源的访问权限安全地交给第三方应用”这件事的规则。你可以把它理解成酒店的门卡系统——前台验证你的身份后，给你一张只能开特定楼层、特定时间有效的门卡，而不是直接把万能钥匙交给你。这个思路贯穿整个协议，搞懂了这一点，后面的所有概念都能串起来。
这篇文章我会把 OAuth 2.0 从零拆开讲：先看它解决什么痛点，再梳理四个角色和四种授权模式，接着重点拆解授权码模式的完整流程，然后聊 Token 的设计逻辑，最后把我在实际对接中踩过的坑和排查思路一并整理出来。无论你是刚接触 OAuth 的新手，还是对接过但总有些细节没想通的开发者，这篇应该都能给你一些参考。
1. 内容整体设计与思路拆解
1.1 OAuth 2.0 到底是什么：从“账密共享”到“授权委托”
要理解 OAuth 2.0，最好的切入点是先看看没有它的时候，第三方应用是怎么拿用户数据的。
很早之前，一个第三方网站如果想让用户导入邮箱联系人，最粗暴的做法是让用户把邮箱账号和密码直接交出来。这种模式最大的问题在于：你把万能钥匙给了别人，对方能看你的邮件、能删你的邮件、能改你的密码——你完全无法限制它只能做某一件事。而且一旦这个第三方网站的数据库被拖库，你的邮箱密码也就跟着泄露了，连带你的主邮箱可能都被撞库。
OAuth 2.0 的诞生就是为了解决这个“过度授权”的问题。它的核心思想是“委托授权”，也就是用户本人在授权服务器上确认“我允许这个应用读取我的联系人列表”，然后授权服务器发给第三方应用一个访问令牌（Access Token），这个令牌有过期时间、有权限范围，而且只针对某一个资源服务器有效。第三方应用拿着这个令牌去换数据，全程不需要看到用户的密码。
类比来说，这就是酒店前台的做法。你去住酒店，前台确认你的预订信息后，给你一张房卡，房卡只能开你自己的房间，而且退房后自动失效。你不需要把酒店的总控钥匙交给任何人，服务员打扫房间用的也是单独的员工卡，权限是分级的。OAuth 2.0 就是这套门禁系统的协议化。
1.2 为什么用授权码模式，而不是直接返回 Token
OAuth 2.0 官方定义了四种授权模式：授权码模式、隐式模式、密码模式和客户端凭证模式。其中授权码模式是应用最广、安全性最高的方案，也是我强烈推荐你在 Web 应用中优先选择的方案。原因在于它绕开了“Token 经过前端”这个最大的安全风险点。
这套模式的名字叫“授权码”，核心逻辑是分两步走：第一步，授权服务器先返回一个短期有效的授权码（Authorization Code），而且这个码是通过后端服务端重定向的方式交给客户端的；第二步，客户端拿这个授权码，再配合客户端自己的密钥，在后端向授权服务器换取 Token。
为什么这么绕？因为授权码是短期的、一次性的，而且单独泄露授权码本身问题不大——因为它必须搭配客户端密钥（Client Secret）才能换到 Token，而客户端密钥是保存在后端服务器上的，前端拿不到。Token 也一样，通过后端的服务端到服务端通信获取，不经过浏览器，这样就大大降低了 Token 被脚本注入窃取的风险。你可以理解成：授权码是一张“验票凭证”，它本身不是门票，你得在检票口（后端）拿着它和身份证一起验，才能换到真正的门票（Token）。
我在实际项目里见过不少团队为了图省事，直接把用户重定向到授权页面，然后把 Token 放在 URL 参数里返回。这种做法的隐患很大——URL 会被浏览器历史记录、代理服务器日志、Referer 头等地方暴露，Token 一旦被第三方拿到，你的资源就相当于裸奔了。授权码模式虽然多了一次跳转和一次请求，但安全收益是实打实的。
1.3 参数设计里的核心考量：状态码与作用域
除了分步换 Token 这件事，授权码模式里还有两个容易被忽略但极其关键的参数：state（状态参数）和scope（作用域参数）。
state 参数的用途是防 CSRF（跨站请求伪造）。它的工作方式是这样的：在发起授权请求时，客户端先生成一个随机字符串存在自己的会话里，然后把这个字符串作为 state 参数拼在授权 URL 上；授权服务器回调时会把 state 原样带回来；客户端在回调接口里比对这个值是否和会话里的一致，如果不一致，直接拒绝这次回调。这样就能防止攻击者构造一个授权回调 URL 诱导用户访问，从而劫持用户的授权结果。
scope 参数则用来控制授权范围。比如一个应用只需要读取用户的公开信息，那 scope 就只申请read:user，不需要申请read:repo甚至write:repo。这是一个“最小权限”原则的落地——你在授权页面申请多少权限，用户就能看到多少权限，申请太多反而会让用户产生警惕心理，降低转化率。实际对接 GitHub、Google 这类平台的开发者可能都有印象，它们的授权页面上会明确列出“这个应用将获得以下权限”，这就是通过 scope 控制的。
2. 核心角色与授权流程详解
2.1 四个角色的职责划分：谁在做什么
OAuth 2.0 的整个流程里一共涉及四个角色，我把它们对应到现实场景里来理解：
- 资源所有者（Resource Owner）：就是用户本人，拥有资源服务器上的数据。他能决定是否允许第三方应用访问他的数据。
- 客户端（Client）：就是你想接入的那个第三方应用，比如一个待办事项 App 想读取你的日历。这里的“客户端”不一定是前端 App，它可以是任何需要访问资源的软件。
- 授权服务器（Authorization Server）：负责验证资源所有者的身份，并颁发授权码和 Token。它通常和资源服务器是同一套体系里的不同逻辑模块，比如 GitHub、微信开放平台的统一授权中心。
- 资源服务器（Resource Server）：存储用户数据的服务，比如 GitHub 的
/user接口。它负责校验 Token 的有效性和权限范围，然后返回相应的数据。
需要特别提醒的是，授权服务器和资源服务器可以是同一个应用，也可以是分开部署的两个服务。很多企业在内部做微服务改造时，会把授权服务器单独拆出来做一个统一认证中心，各个业务系统作为资源服务器接入。这样做的好处是账号体系和业务数据解耦，权限控制可以统一管理，缺点是引入了一个高可用要求极高的单点——认证中心挂了，所有依赖它的业务都登录不了。
2.2 四种授权模式对比：各自适用的场景
OAuth 2.0 的四种模式不是并列关系，而是针对不同的客户端类型设计出来的。我在做技术选型的时候，第一件事就是确认客户端是什么类型，这决定了用哪种模式。
| 授权模式 | 适用客户端类型 | 核心特点 | 安全级别 |
|---|---|---|---|
| 授权码模式 | 后端参与的 Web 应用、移动应用 | 分两步换 Token，客户端密钥由后端保管 | 最高 |
| 隐式模式 | 纯前端 SPA、无后端参与 | 直接在回调 URL 里返回 Token，不经过授权码 | 较低，官方已建议弃用 |
| 密码模式 | 自家前后端、高信任度场景 | 用户直接把用户名密码交给客户端，客户端换 Token | 仅限信任场景，不适合第三方 |
| 客户端凭证模式 | 服务间通信、机器对机器 | 没有用户参与，客户端以自己的身份换 Token | 适用于后台服务 |
这里面我想多说一下隐式模式。在 OAuth 2.0 刚发布的年代，纯前端单页应用很流行，隐式模式看起来是个好方案：不需要后端，前端重定向拿 Token 就能用。但它有两个硬伤：Token 暴露在 URL 中，容易被日志和 Referer 泄露；前端没有安全存储 Token 的手段（localStorage 和 Cookie 都有各自的漏洞面）。因此 OAuth 2.1 草案里已经明确要把隐式模式移除，取而代之的是授权码模式 + PKCE（Proof Key for Code Exchange，代码交换证明密钥）的组合方案。PKCE 的本质是：即使客户端是公开的（无法安全保存密钥），也能通过一个动态生成的 code_verifier 来证明发起授权请求的就是换取 Token 的那个应用。如果你现在在写纯前端应用，建议直接上这个方案，而不是沿用隐式模式。
2.3 什么时候用刷新令牌，什么时候用访问令牌
关于 Token，初学者最常见的困惑是搞不清**访问令牌（Access Token）和刷新令牌（Refresh Token）**的区别。简单来说，访问令牌是用来访问资源的，它有效期短（一般是 1 到 24 小时）；刷新令牌是用来换新的访问令牌的，它的有效期更长（几天到几个月），而且必须存放在安全的后端环境中。
为什么不直接让访问令牌的有效期也变长呢？因为访问令牌是“亮出来用”的，它一旦发了出去，你就很难控制它在哪里被记录、被缓存。如果有效期过长，泄露后的风险窗口就很大。刷新令牌虽然也有泄露风险，但它只在后端和授权服务器之间流通，攻击者获取它的难度大得多。而且刷新令牌可以被撤销——比如用户在账号安全设置里“注销所有已登录设备”，后端把自己的刷新令牌记录删掉就行，但这种做的前提是刷订令牌在你的系统里是可追踪、可撤销的。
我在项目里经常看到一种错误设计：把刷新令牌也当成普通的 Token 存在浏览器 localStorage 里，然后每次刷新 Token 都从前端发起请求。这等于把两把钥匙都挂在门外，毫无安全性可言。正确做法是：访问令牌可以短期保存在内存里，刷新令牌一定要存储在后端，前端完全不应该接触它。
3. 实操过程与核心环节实现：授权码模式全流程
本节是全文的重点。我会以“一个待办事项 App 调用 GitHub 获取用户信息”为例子，完整拆解一次授权码模式的流程。
3.1 前置准备：在 GitHub 上注册应用并获取客户端凭证
动手之前，先在 GitHub 的开发者设置里注册一个 OAuth App。这里有个初学者容易忽略的点：回调地址（redirect_uri）必须和你代码里实际使用的地址完全一致，包括协议、域名、端口和路径，差一个斜杠都不行。我见过最经典的坑是把回调地址填成http://localhost:8080/callback，但本地开发时实际监听的是http://127.0.0.1:8080/callback，结果 GitHub 一直报redirect_uri mismatch。
注册完成后，你会拿到两组关键凭证：
- Client ID：公开的，可以放在前端代码里，用于标识你的应用。
- Client Secret：私密的，必须保存在后端，泄露了等于你的应用可以被任何人冒充。
把这组凭证记录好，后面代码里要用到。为了演示方便，我这里用 Node.js 和 Express 写一个最小实现，但思路可以平移到你用的任何语言和框架。
3.2 第一步：构建授权链接，引导用户授权
当用户点击“使用 GitHub 登录”时，后端需要生成一个授权链接，然后让浏览器重定向过去。这个链接指向授权服务器的/authorize端点，关键参数如下：
https://github.com/login/oauth/authorize ?client_id=你的ClientID &redirect_uri=http://localhost:8080/callback &scope=read:user &state=随机生成的字符串代码实现大致是这个样子：
// server.js const express = require('express'); const crypto = require('crypto'); const app = express(); // 用内存存储 state，生产环境建议存在 Redis/Session 中，设置过期时间 const stateStore = new Map(); app.get('/login', (req, res) => { const state = crypto.randomBytes(16).toString('hex'); stateStore.set(state, { createdAt: Date.now() }); const authorizeUrl = 'https://github.com/login/oauth/authorize' + '?client_id=' + process.env.CLIENT_ID + '&redirect_uri=' + encodeURIComponent('http://localhost:8080/callback') + '&scope=read:user' + '&state=' + state; res.redirect(authorizeUrl); });注意这里的scope参数。GitHub 的read:user表示只读取公开的用户资料，这是最小的权限申请。如果你后续要读取用户的仓库列表，再考虑扩展 scope，不要一开始就申请所有权限。
3.3 第二步：接收回调，校验 state 并换取 Token
用户点击“授权”之后，GitHub 会将浏览器重定向回你的回调地址，并在 URL 上附带两个重要参数：code和state。此时你的后端需要在回调接口里做三件事：
- 校验
state是否与会话中存储的一致，防止 CSRF。 - 取出
code，用它去授权服务器的/access_token端点换 Token。 - 将 Token 存储到后端会话或数据库中，然后给前端一个登录成功的信号。
以下是完整的回调处理代码：
app.get('/callback', async (req, res) => { const { code, state } = req.query; // 1. 校验 state，防止 CSRF if (!stateStore.has(state)) { return res.status(400).send('state 不匹配，请求可能被篡改'); } stateStore.delete(state); // 一次性使用，用完即删 if (!code) { return res.status(400).send('缺少授权码'); } // 2. 用 code 换 Token，这一步必须在后端完成 const tokenResponse = await fetch('https://github.com/login/oauth/access_token', { method: 'POST', headers: { 'Accept': 'application/json', 'Content-Type': 'application/json', }, body: JSON.stringify({ client_id: process.env.CLIENT_ID, client_secret: process.env.CLIENT_SECRET, code: code, redirect_uri: 'http://localhost:8080/callback', }), }); const tokenData = await tokenResponse.json(); if (tokenData.error) { console.error('换取 Token 失败:', tokenData.error_description || tokenData.error); return res.status(500).send('授权失败'); } // 3. 保存访问令牌，建议存到 Redis / 数据库中，并关联到当前用户 // 这里为了演示，简单设置一个 Cookie const sessionId = crypto.randomBytes(16).toString('hex'); sessions[sessionId] = { access_token: tokenData.access_token, refresh_token: tokenData.refresh_token || null, expires_at: Date.now() + (tokenData.expires_in || 3600) * 1000, }; res.cookie('session_id', sessionId, { httpOnly: true }); // 前端拿到登录成功信号后，可以跳转到用户首页 res.redirect('/dashboard'); });这里有几个实操要点：
- code 是一次性的：用了一次之后再重复用，授权服务器会返回
invalid_grant错误。 - Client Secret 绝对不能在浏览器里出现：这个请求只能由后端发起，否则任何人都可以用截获的 code 冒充你的应用换 Token。
- state 建议设为一次性且有过期时间：上面的实现里每次用完即删，同时在查找时检查
createdAt是否过期，避免 state 值长期有效。
3.4 第三步：携带 Token 访问资源服务器
拿到访问令牌之后，你的应用要请求 GitHub 的/user接口来获取用户信息。这一步很简单，在请求头里加一个Authorization字段即可：
app.get('/dashboard', async (req, res) => { const session = sessions[req.cookies.session_id]; if (!session || Date.now() > session.expires_at) { return res.status(401).send('登录状态已过期，请重新登录'); } const userResponse = await fetch('https://api.github.com/user', { headers: { 'Authorization': 'Bearer ' + session.access_token, 'Accept': 'application/json', }, }); if (userResponse.status === 401) { // Token 失效，需要走刷新逻辑 return res.status(401).send('Token 已失效，请刷新登录状态'); } const userData = await userResponse.json(); res.json({ login: userData.login, name: userData.name, avatar: userData.avatar_url }); });这条链路里，最需要做好的防御是：不要在日志里打印 Authorization 头。很多团队排查线上问题时习惯把请求头打印出来，这一打，Token 就进了日志系统，如果日志又被同步到第三方分析平台，风险面就大大扩大了。我通常会要求团队在日志链路里加一条脱敏规则，所有Authorization头统一打码为Bearer ***。
3.5 第四步：刷新 Token，保持会话长期有效
访问令牌的有效期通常不长（GitHub 的 token 有效期默认是 8 小时）。用户第二天回来，你会发现他的 Token 已经过期了。这时如果有刷新令牌，就可以静默换一个新的访问令牌，用户完全无感知。
async function refreshAccessToken(refreshToken) { const response = await fetch('https://github.com/login/oauth/access_token', { method: 'POST', headers: { 'Accept': 'application/json', 'Content-Type': 'application/json', }, body: JSON.stringify({ client_id: process.env.CLIENT_ID, client_secret: process.env.CLIENT_SECRET, grant_type: 'refresh_token', refresh_token: refreshToken, }), }); const data = await response.json(); if (data.error) { throw new Error('刷新 Token 失败: ' + data.error_description); } return { access_token: data.access_token, refresh_token: data.refresh_token || refreshToken, // 某些服务会轮换刷新令牌 expires_in: data.expires_in, }; }关于刷新令牌，这里有三个值得注意的细节：
- 刷新令牌是否轮换：有些授权服务器会在每次刷新时返回一个新的刷新令牌，旧的就作废了；有些则保持不变。如果你的授权服务器支持轮换，建议启用，这样即使刷新令牌被泄露一次，也无法长期使用。
- 刷新令牌也分 scope：刷新后新拿到的访问令牌，权限范围和原始的刷新令牌一致，不会凭空扩大。
- Refresh Token 泄露怎么办：因为刷新令牌生命周期长，一旦泄露影响很大。好的方案是给刷新令牌绑定设备信息，比如浏览器指纹、IP 段，如果检测到异常地点使用就要求重新登录。
4. Token 的本质与安全存储设计
4.1 Access Token 的格式：Opaque Token 与 JWT
访问令牌的格式没有统一规定，但实际使用中可以分成两大类。一类是不透明令牌（Opaque Token），就是一串随机字符串，资源服务器拿到后要去授权服务器查一下才知道有没有效；另一类是JWT（JSON Web Token），令牌本身携带了用户信息、scope、过期时间等元数据，资源服务器只需要验证签名就可以判断令牌有效。
两种格式各有取舍。JWT 的优势是无状态，资源服务器不需要存储 Session 或者每次远程验证 Token，对水平扩容非常友好；缺点是一旦签发就无法在到期前撤销（除非引入额外的黑名单机制），而且 payload 里如果塞太多信息会导致 Token 体积膨胀。不透明令牌则相反，它可以随时被撤销，但因为资源服务器每次都要去授权服务器验证令牌有效性，会增加一次网络往返延迟。
这里我想展开说一个 JWT 的误用：把敏感数据塞进 payload。JWT 的 payload 只是 Base64 编码，不是加密的，任何人拿到 Token 用 base64 解码就能看到里面的内容。如果你在 payload 里放了手机号、邮箱、身份证号，相当于把用户隐私明文发给所有能截获 Token 的人。正确的做法是 payload 只放sub（用户标识）、scope、iss、exp这类元数据，真正要读的敏感信息还是通过接口去拿。
4.2 令牌保存在哪里：浏览器端和后端的不同策略
开发者在对接 OAuth 2.0 时，最常争论的问题就是 Token 到底该存哪。我这个项目里踩过不少坑，结论是：没有绝对安全的存储位置，只能根据业务场景选一个风险最小的方案。
如果你的应用有后端参与，最佳实践是：
- 访问令牌：保存在后端的内存变量或 Session 中，前端需要用的时候由后端代为请求。
- 刷新令牌：保存在后端数据库中，并关联用户 ID 和会话 ID，支持随时撤销。
- 前端：只保存一个不透明的会话标识（Session ID），用 HttpOnly Cookie 传递。
纯前端方案（没有自建后端）的话，令牌只能存在浏览器里，选项只有 localStorage、sessionStorage、IndexedDB、Cookie 这几个。它们各自的弱点如下：
| 存储位置 | 优点 | 风险 |
|---|---|---|
| localStorage | 简单、跨标签页共享 | XSS 攻击可直接读取 |
| sessionStorage | 仅当前标签页有效 | XSS 攻击仍可读取，刷新后不丢但关闭标签页会丢 |
| IndexedDB | 容量大、适合离线数据 | XSS 攻击仍可读取 |
| Cookie（HttpOnly） | XSS 无法读取 | 防御 CSRF 成本高，需要考虑 SameSite 策略 |
我的建议是：纯前端应用也要尽力减少 Token 在浏览器的暴露时间。可以把访问令牌放在内存变量中，每次页面刷新后重新走一遍静默授权流程（用 iframe 嵌入隐藏的授权页 + PKCE 自动换码），而不是直接扔进 localStorage。虽然这样用户每次刷新页面都得等一个异步授权过程，但换取的是更高的安全性，值得。
4.3 scope 的最小权限实践：不要贪多
scope 是 OAuth 2.0 里约束“这个令牌能干多少事”的机制。我在对接第三方平台时，见过一些应用的授权页列了一大堆权限——包括读取仓库、删除仓库、修改个人信息——但实际功能只需要一个“读取用户名”。这不仅是体验问题，还是风险问题：一旦你的应用被攻破，攻击者拿到的令牌权限就等价于你申请的权限。
正确的做法是：每个功能单独申请 scope，尽量解耦。比如你的应用既需要读用户信息，又需要代表用户发推文，那就申请两个独立的 scope，发推文的接口只在用户真正触发发推动作时才需要对应的令牌，其他时候用只有只读权限的令牌就够了。
5. 常见问题与排查技巧实录
5.1 redirect_uri 不匹配
这是对接 OAuth 2.0 时出现频率最高的错误，报错信息通常是redirect_uri mismatch或者The redirect_uri included is not valid。
排查步骤：
- 确认授权服务器后台配置的域名和代码里实际使用的完全一致。注意协议（http vs https）、域名（example.com vs www.example.com）、端口（默认 80 还是 8080）、路径（/callback vs /callback/）。
- 确认有 URL 编码，特别是回调地址里带了参数时，要整体做一次 encodeURIComponent。
- 确认授权链接里的 redirect_uri 拼写是否正确，有没有多空格或者漏字符。
5.2 授权码失效或已使用（invalid_grant）
授权码的有效期通常非常短（有的只有 1 到 5 分钟），而且是一次性的。如果你在本地调试时反复重放同一个授权请求，往往第二次就会遇到invalid_grant。
排查步骤：
- 确认没有在前端代码里尝试用自己的 Client Secret 换 Token，因为
code是用一次就作废的。 - 确认换了 Token 后没有再次拿同一个 code 去换（有些框架会自 动重试，需要注意幂等性）。
- 确认系统时间没有偏差过大，尤其是授权服务器对你的请求做了时间戳校验的场景。
5.3 Token 过期，怎么处理 401
如果你在访问资源服务器时收到 401 Unauthorized，先不要急于重新走一遍完整授权流程，检查一下刷新令牌还在不在，能不能正常刷新。
我在项目里遇到过一种情况：访问令牌过期后，客户端没有捕抓 401，而是直接跳转到了登录页，用户一刷新又回到首页，然后又请求，又 401，形成一个死循环。后来我们统一封装了一个 HTTP 客户端，在响应拦截器里处理 401：第一次收到 401 时尝试静默刷新访问令牌，刷新成功就自动重放原来的请求；刷新失败才引导用户重新登录。这样用户基本感知不到令牌过期的过程。
5.4 state 参数校验失败
有时候回调接口收到 state 但校验不过，多数情况是了 session 或 redis 中保存的 state 与回调的不一致。常见原因包括：
- 用户同时打开了多个页面，前一个页面的 state 被后一个覆盖了。
- 授权跳转和回调落在不同的集群节点上，而 state 存在单机内存里没有共享。
- 浏览器隐私模式下 Cookie 不持久，导致 state 丢失。
解决方向是把 state 存储在可跨节点共享的存储中（比如 Redis），设置 5 分钟过期时间，并在生成 state 时绑定当前用户会话 ID。
5.5 常见问题速查表
| 现象 | 大概率原因 | 排查优先级 |
|---|---|---|
| redirect_uri mismatch | 回调地址配置不一致 | 1. 核对后台配置；2. 核对 URL 编码 |
| invalid_grant | code 已失效或重复使用 | 1. 检查是否重复请求；2. 检查授权码有效期 |
| 401 Unauthorized | 访问令牌过期或无效 | 1. 尝试刷新令牌；2. 检查 scope 是否匹配 |
| scope 不符合预期 | 申请 scope 与使用场景不匹配 | 1. 确认授权时的 scope；2. 查看 Token 实际权限 |
| 用户授权后跳回空白页 | 回调接口报错未处理 | 1. 查看后端日志；2. 检查回调地址是否有非法参数 |
6. 安全实践与避坑经验
6.1 生产环境必须做的四件事
很多 OAuth 2.0 的接入事故，根源不在协议本身，而是把生产环境的配置按开发环境的习惯来。根据我自己的经验，生产环境上线前至少要做这四步加固：
- 强制使用 HTTPS：Token 在 HTTP 下传输等于明文传输，抓包就能看到。不要在 HTTP 环境下提供任何授权接口。
- 启用 PKCE：即使你的应用有后端，PKCE 也能提供额外一层保护，防止授权码被其他应用截获后使用。
- 对 Token 做加密存储：访问令牌和刷新令牌在数据库里不能明文存放，建议用 AES-256 或 KMS 加密；刷新令牌还要加哈希索引以便快速查询和撤销。
- 设置合理的 Token 过期时间：不要图省事把访问令牌的有效期设成 7 天。访问令牌一般是几十分钟到几小时，刷新令牌一般不超过 30 天，具体看业务场景。
6.2 用户退出登录时，要清理哪些东西
“退出登录”在 OAuth 2.0 体系里不是清除本地 Cookie 就完事的，需要做三件事：
- 删除本地会话（Cookie/Session）。
- 吊销授权服务器上的刷新令牌和访问令牌（如果授权服务器提供 revoke 接口）。
- 撤销应用与用户之间的授权记录，确保后续无法通过旧的刷新令牌换到新 Token。
很多授权服务器提供了POST /revoke接口，调用时需要带上客户端凭证和要撤销的 Token。我在项目里见过一个坑：只删了本地会话，忘了调 revoke，结果用户的刷新令牌在授权服务器上还有效，攻击者只要拿到这个令牌就能一直换新 Token，用户即使点了退出登录，账号还是被人控制着。所以退出登录的接口一定要把“撤销远端令牌”这一步补上。
6.3 日志与监控：别把 Token 写进日志里
前面已经提到过日志脱敏的重要性，这里我再展开一点。实际排查问题时，最容易泄密的日志场景有：
- 捕获第三方接口回调的参数后，把整个 query string 打出来（里面可能带着 code）。
- 在调试阶段打印了请求头，包含 Authorization。
- 把整个响应体打出来，而响应体里可能包含了 access_token。
建议在项目里引入日志脱敏工具，对client_secret、access_token、refresh_token、code等敏感字段统一打码，同时在监控面板上设置告警，检测到日志中出现疑似 Token 的字符串就自动告警。
7. 结尾：一点个人体会
做了这么多年技术，我最大的感受是：OAuth 2.0 这套协议，看着抽象，但只要你动手接一次第三方登录，再钻进去看一遍交互流程，很多概念自然就通了。它本质上就是在回答一个问题——如何在不交出密码的前提下，安全地把资源访问权限委托给第三方。搞清楚了这个问题，后面再看 OIDC（OpenID Connect）、PKCE、Token 轮换这些进阶话题，都是一通百通。
最后再说一个小技巧：本地调试 OAuth 2.0 时，建议直接在本地起两个项目——一个是授权服务器（可以自己写个 Spring Boot 或者 Node 版的最小实现），一个是客户端应用。用真实交互代替单纯读文档，很多容易混淆的细节（比如 code 是一次性的、state 要防重放、scope 最小化）都会在你亲手踩过坑之后记得非常牢。这也是我个人最推荐的入门方式。
