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

前言

如果给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的时候还会着重讲解】

🎈refreshToken为什么就更安全？

1. 因为 refreshToken 是保存在客户端的，并不是每次请求都会携带，只有在需要续签的时候才会带上，并且用完一次就过期了，相对更安全一点。
2. 一般 refreshToken 还会绑定客户端client_id，不允许任何客户端都能调用【类似Oauth2.0中的用code获取accessToken的过程】

缺点

• 重新请求获取 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

这篇好文章是转载于：学新通技术网