@lusxh 操作上当然都可以，你把 refreshtoken 做成过期时间很长的 jwt ，每次校验 refresh 的时候也不用过数据库。问题就在于这样做拆分就没有意义了，直接用 access token 校验不就好了么。你这样问的就是，我不查数据库有没有办法维护一个 token 的状态，那答案肯定是否定的。 不过 oauth2.0 并没有规定这些乱七八糟的，这个框架只明确规定了客户端应该利用获取 access token 这个行为来获得第三方网站的授权，注意是第三方，而不是在客户端上直接输入第三方网站的密码来获取授权。access token 在标准里也就说了是一个授权字符串，refresh token 是获取 access token 的字符串，根本没人管你怎么验证。你实现成第三方客户端只要把 114514 填进 access token 发给你就算 Authorized ，refresh token 只要是 1919810 你就返回 114514 都没人管你。 只不过后面 jwt 等无状态 token 的技术出现了，大家就开始往这个标准上套，然后总结出一套最佳实践就是无状态 access token+有状态 refresh token ，其中无状态 access token 就可以直接用 jwt 的方式实现（也有不用 jwt 的，google oauth api 就不是 jwt ）。这样不管是第一方还是第三方的验证，都可以在无状态和有状态验证的优缺点之间取得一个平衡。还有不少人其实连 oauth 2.0 一开始是给第三方授权的都不知道，第一方授权也这么写,然后不知道这标准为什么要这么定义，就去硬套说什么给用户无感刷新用，这就是为了凑个理由强行说了。你第一方对自己的客户端，直接把 refreshtoken 做成 jwt 一直无状态也没人管你，反正发行 token 的时候用户肯定要敲账号密码的，账号密码也都存在你这里，谁来管你呢？

jwt 本质上只是把用户 id 进行编码,加上域名用于验证,加上过期时间用于判断是否可用 主要信息传的还是用户 id jwt 优于 cookie 和 session 的点在于 后者受限于浏览器机制限制,对同源策略不友好,在 app 等非浏览器环境下适配性更好, 在微服务架构中网关处理更加方便, 安全方面由于不在 cookie 中传输,所以天然防御 CSRF 攻击 单 jwt Token 续签流程,用的就是短过期时间 例如 30 分钟 + 长过期时间标记 例如 7 天, 当短过期时间过期: 拒绝请求，返回过期错误，要求前端用旧 Token 请求刷新接口, 长过期时间过期 则返回 401 要求重新登陆 至于 Refresh Token 刷新令牌是 OAuth 2.0 授权框架中的概念, 使用 Refresh Token 长有效期刷新 Access Token 短有效期, 比单 Token 机制更加安全

客户要求登出后 token 必须失效，直接又把 jwt 扔 session 里了🤣

@sentinelK 为了性能，反而丢失了一定时间的安全性

@sentinelK 中文的博大精深，错误命题，问出来了一大推正确答案。

@photon006 Refresh Token 到期也面临这个问题么。

@litchinn 答案是其实根本就不需要续签，针对第一方应用的时候，验证信息（账号密码 passkey 等）全都保存在第一方后端里，发行任何 token 都需要完整信息验证，这种情况下是续签是为了续签而续签(降低数据库访问），是实际操作上的处理，而并非 refresh token 设计出来的本意。oauth 2.0 之所以设置成两个 token ，是因为标准上来说，oauth2.0 希望客户端无法知道第三方给的 access token 内部的具体细节，而给了 refresh token 就相当于第三方信任了当前客户端，并且留了一手可以随时撤销授权的能力。 在进行授权操作的时候，第三方完全可以不给 refresh token ，只给 access token （比方说第三方登录的时候只给一个 access token 来让当前客户端拿到用户名，不给继续访问后续信息的权限）。

@zxjxzj9 大家看看这老哥的答案。我也感觉，我自己写的系统为什么要用双 token ，没感觉双 token 那里好么，下次面试碰到这种问题，就这么回答了。

我对双 token 的理解比较粗浅，用途上 access token 是给一个相对较短有效期的授权，而 refresh token 则是用来续签的，有效期较长，给受信任的客户端环境才签发。在 access token 有效期内无需重新登录，在 refresh token 有效期内无感续签，比如本次登录没勾选保持登录状态，access token 可在本次会话中一直使用只要你别关闭浏览器，关闭标签页重新开个网页依旧是登录状态的；如果登录时勾选了保持登录状态，那么 refresh token 应该是持久化保存的，重开浏览器什么的依旧可以维持登录状态，因为你的客户端可以拿 refresh token 去重新签一个 access token 。而超过 refresh token 有效期了则强制要求登录一次验证身份，这是一种很简单的安全手段。至于数据库存不存查不查那实际上是看会话管理上需不需要，实际上可以不要的

@lusxh #37 90%的场景，把 session 丢 header 即可。什么 jwt 来的都不需要