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

语言: CN / TW / HK

theme: smartblue highlight: solarized-light


持续创作,加速成长!这是我参与「掘金日新计划 · 10 月更文挑战」的第 5 天,点击查看活动详情

大家好,我是melo,一名大三后台练习生,不知不觉练习时间长达一年了!!!

👉本篇速览

  • 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错误码。 ```java 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:表示申请的授权范围,不可以超出上一次申请的范围,如果省略该参数,则表示与上一次一致。

```java 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

💠下篇预告

  • 本篇就JWT续签问题和OAuth2.0展开了解读,也算是浅提及到了OAuth2.0机制,后续的SSO单点登录基于ticket形式实现,其中就借鉴了OAuth2.0中的授权码机制。
  • 聊完了前置知识,Cookie和Session以及JWT,下篇我们将正式进入SSO单点登录篇,展开第一种SSO单点登录方式--基于Cookie和Session实现,敬请期待~

🧿友链