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的关系，用户主动退出，需要清除它的关系
/auth/realms/lind 来查看iss颁发的分钥信息

{
    "realm":"lind",
    "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)
    }

标签 key, SE, token

keycloak~再说session和token

session【session_state】

token