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