@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 的时候用户肯定要敲账号密码的，账号密码也都存在你这里，谁来管你呢？