【SSO单点登录】JWT续签问题 && OAuth2.0 中的refreshToken刷新机制

本篇速览

• JWT续签问题

  • 快过期时返回新的token

  • refreshToken

    • 如何判断refreshToken的有效性

    • 扩展 -- OAuth2.0 中的refreshToken刷新机制

  • 其他需要刷新token的情况

    • 用户修改了角色权限
    • 删除了某个身份角色

为什么需要续签

如果给JWT设定了一个有效时间的话，时间到JWT是会过期的。但假如这个时候用户正在提交重要信息，填了一大堆信息，按下按钮时，后台拦截器发现token过期，告知前端，前端直接退回登录页，那这次提交就相当于无效了，还得登录后重新填一遍【当然前端也能做缓存，这里就不考虑那么多了，只是个栗子】

而原始JWT设计下，是没有考虑续签问题的。所以续签（即延长JWT的过期时间）工作需要我们自己来做。

快过期了返回新的token

类似于 Session 认证中的做法： 假设服务端给的 token 有效期设置为30分钟，服务端每次进行校验时，如果发现 token 的有效期马上快过期了， 服务端就重新生成 token 给客户端。

客户端每次请求都检查新旧token，如果不一致，则更新客户端存储的token。

• 这种做法的问题是仅仅在快过期的时候请求才会更新 token ,对客户端不是很友好。

refreshToken刷新机制

流程图

用户登录返回两个 token ：第一个是 acessToken ，它的过期时间比较短，比如是1天；另外一个是 refreshToken 它的过期时间更长一点，可以是accessToken的2倍：2天。

客户端登录后，将 accessToken和refreshToken 保存在客户端本地，每次访问将 accessToken 传给服务端。服务端校验 accessToken 的有效性，

如果过期的话，就将 refreshToken 传给服务端。如果 refreshToken 有效，服务端就生成新的 accessToken 给客户端。否则，客户端就重新登录即可。

如何判断refreshToken的有效性

将生成的 Refresh Token 以及过期时间存储在服务端的数据库中，由于 Refresh Token 不会在客户端请求业务接口时验证，只有在申请新的 Access Token 时才会验证，所以将 Refresh Token 存储在数据库中，不会对业务接口的响应时间造成影响，也不需要像 Session 一样一直保持在内存中以应对大量的请求。

当然，更安全的方式是，客户端需要绑定一个client_id和secret，服务端会验证这个refreshToken是否是改客户端发起的，防止被盗用【这个是后话了，我们后续基于token的SSO单点登录，验证令牌ticket的时候还会着重讲解】

缺点

• 重新请求获取 token 的过程中会有短暂 token 不可用的情况（可以通过在客户端设置定时器，当accessToken 快过期的时候，提前去通过 refreshToken 获取新的accessToken）。

扩展 -- OAuth2.0中的刷新机制

客户端在获得access token的同时也会在响应信息中得到一个名为expires_in的数据，它表示当前获得的access token会在多少秒以后过期。 当超过该指定的秒数后，access token便会过期。当access token过期后，如果客户端依然用它访问服务，服务端就会返回invalid_token的错误或401错误码。

HTTP/1.1 401 Unauthorized
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
    "error": "invaild_token"
}

如果用户访问的时候，客户端的"访问令牌AccessToken"已经过期，则需要使用"更新令牌refreshToken"申请一个新的访问令牌。

客户端发出更新令牌的HTTP请求，包含以下参数：

• granttype：表示使用的授权模式，此处的值固定为"refreshtoken"，必选项。
• refresh_token：表示早前收到的更新令牌，必选项。
• scope：表示申请的授权范围，不可以超出上一次申请的范围，如果省略该参数，则表示与上一次一致。

POST /v1/oauth2/token HTTP/1.1
Host: melo.com
Authorization: Bearer zskldjflsdjflksjdflkjsd
Content-Type: application/x-www-form-urlencoded

grent_type=refresh_token&refresh_tokne=ajsldkjflskdfjldfg

其他需要刷新token的情况

用户修改了角色的权限

由于权限是在登录的时候，绑定在token里边了，若登录后，管理员修改了角色的权限，而服务端此时还拿一开始登录的token去获取权限的话，就会出现不同步，所以需要主动刷新token更新权限

删除了某个身份角色

情况跟上边是类似的，本质上也是身份权限发生了变更，只要是token中的信息，发生了变化，而我们之后还要用到，会出现数据不一致的情况，就需要刷新token