我們需要認清session會話和token令牌的區別，在keycloak中，他們是不同的兩個概念，職責也不一樣。

session【session_state】

它被保存到瀏覽器的cookie中，有4個會話屬性，這主要基于高低版本瀏覽器和記住我功能考慮而設計的

按著kc系統獲取會話的優先級，他們分別是：【帶_legacy是為了適應不支持samesite屬性的瀏覽器】

1. auth_session_id（支持samesite屬性，會話級，關閉瀏覽器后過期）
2. auth_session_id_legacy
3. keycloak_session_id （開啟了KEYCLOAK_REMEMBER_ME后，設置了過期時間，會在cookie添加這個屬性)
4. 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)
    }