本篇文章为你整理了keycloak~再说session和token（）的详细内容，包含有 keycloak~再说session和token，希望能帮助你了解 keycloak~再说session和token。

　　我们需要认清session会话和token令牌的区别，在keycloak中，他们是不同的两个概念，职责也不一样。

　　session【session_state】

　　它被保存到浏览器的cookie中，有4个会话属性，这主要基于高低版本浏览器和记住我功能考虑而设计的

　　按着kc系统获取会话的优先级，他们分别是：【带_legacy是为了适应不支持samesite属性的浏览器】

　　auth_session_id（支持samesite属性，会话级，关闭浏览器后过期）

　　auth_session_id_legacy

　　keycloak_session_id （开启了KEYCLOAK_REMEMBER_ME后，设置了过期时间，会在cookie添加这个属性)

　　keycloak_session_id_legacy

　　会话与浏览器cookie里设计的过期时间有关，与token过期时间无关，当用户退出时，kc服务器保持的会话【session_state】会被删除，如图为kc用户的会话列表
 

　　token

　　由于kc中使用的是jwt(json web token)，所以我们不需要把它再次进行存储了，因为在这个token里已经有了用户信息，并且添加了当前会话信息；而传统的而自解释
 

　　的token，往往需要把它与当前用户作一个对应关系，缓存起来，这点kc的jwt不需要存储。

　　一 根据职责，设置时长

　　access_token 较短的有效期，如30分钟，jwt的token中，会有用户认证和授权的信息

　　refresh_token 较长的有效期，用户最长可接受的，从新登录的时间，如10天

　　二 token的验证

　　在线验证: 为认证服务器压力比较大，相当于去中心化校验，因为kc存储了session_state，可以更准确的知道这个token是否在线

　　离线验证：各个服务端【对接到KC上的客户端】，通过kc颁发的公钥，对token进行签名验证，它可以验证出token是否由当前KC颁发的，对于在线性，它无法直接验证，当然，客户端自己也可以保留session_state，相当于分担KC的在线验证的压力

　　离线验证的属性至少要包括

　　iss,token的颁发机构

　　exp,token的过期时间

　　如果希望验证实时在线性，那你至少要维护session_state与token的关系，用户主动退出，需要清除它的关系

　　
"public_key":"MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyOCNCy8x",

　　 "token-service":"https://kc.com/auth/realms/fabao/protocol/openid-connect",

　　 "account-service":"https://kc.com/auth/realms/fabao/account",

　　 "tokens-not-before":1670507855

　　三 refresh_token使用方式
 

　　refresh_token去刷新token的方式方法，往往争论不休，业界的做法也是多种多样，其中使用最多的，还是在前端添加轮训操作，定时去通过refresh_token去换新的access_token

 refreshToken() {

　　 this.refreshTime = setInterval(() = {

　　 checkToken(this.refreshLock, this.$store)

　　 }, 60000)

　　以上就是keycloak~再说session和token（）的详细内容，想要了解更多 keycloak~再说session和token的内容，请持续关注盛行IT软件开发工作室。

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。