Spring Cloud Micro security services combat _5-6_refresh token failure treatment

access_token is the client calls the tune credentials other micro-services, access_token period not too long (lost a lot of risk), can generally be set two hours, if access_token fails, you can not call a micro-services, the festival said access_token failure processing --- refresh_token to refresh token, refresh_token can set a long period, such as one month

Below is refresh_token refresh token steps of:

1, the configuration refresh_token

 In the list of client application configuration refresh_token valid, then configure refresh_token licensing mode, so the authentication server to the client application access_token hair, it would also send a refresh_token 

(figure 1)

 

 2, when the client application calls the micro-services, from out of the session token, token sentence has expired (when depositing session has set an expiration time of the token), if the token has expired, you get in exchange for access_token from refresh_token:

 (figure 2)

If refresh_token also expired how to handle it?

Although refresh_token a long period (such as month) but will still expire. If refresh_token also expired how to do it?

The answer is: no way. The authentication server can only go away once the certification process.

When to go back to the authentication server authorization process, but also two possibilities:

1, refresh_token although expired, but the session has not expired on the authentication server, take the certification process when the authentication server directly returns a token to the client application.

2, refresh_token although expired, session on the authentication server also expired, then the user must enter a user name and password, to log in again.

1 can control the situation allows users to re-enter your user name and password to log in again, once refresh_token expired, to go again to exit the process, allowing users to log in again (I feel so good, seen a lot of use app is a month to log on the failure)

He began to experiment

1, the client application code

直到上节为止,架构是这样的:在认证服务器登录成功后,客户端应用将认证服务器返回的token存到了自己的session,当调用微服务时,从session中拿出token,放在请求头。如果token已经过期了,就拿refresh_token去认证服务器刷新令牌,然后将新获取的token存到自己的session,并携带新的token去调用微服务。(如图1),刷新令牌失效会哪个地方发生?就在拿着refresh_token去刷新令牌的时候,refresh_token 可以也已经过期,此时就要捕获到这个异常,在刷新令牌的时候,发现refresh_token也过期了,就返回给前端一个500响应码和一个错误信息,前端拿到这个响应码,就去认证服务器走一遍退出流程,让用户彻底退出系统。

图1改造后的代码如下所示

 

 

 (图3)

2,表配置

在客户端应用里,将admin应用的token有效期设为10秒,refresh_token 有效期设为20秒。这样登录后10秒后,token就失效了,再调用订单服务,就会走上边说的刷新token代码,直到20秒后,刷新令牌也失效了,给前端一个错误码500和一个message,前端全局拦截这个错误,调用退出方法。

 

 

 3,前端代码

搞一个全局拦截器,拦截refresh_token失效的响应,因为调用任何服务,都可能返回这个错误响应。

这里使用jquery做的实验(我不会vue和angular),如果是vue获取angular等目前比较流行的框架,思路也是一样的。

 

 

 4,现象

启动几个微服务,登录后调用订单服务,正常

 

 

 token 10秒过期后,refresh_token起效了,刷新了令牌

 20秒后,调用订单服务,自动走退出流程,跳转admin应用的登录页

 

 

 如果refresh_token 失效,还想去认证服务器看看认证服务器的session失效没失效,那就在全局拦截出改成如下代码(我感觉这种体验并不好):

 

 

 本节github代码:https://github.com/lhy1234/springcloud-security/tree/chapt-5-6-refreshtoken-expired  写文章不易,如果对你有帮助了,给个小星星吧!

Guess you like

Origin www.cnblogs.com/lihaoyang/p/12158625.html