我們需要(yao)認(ren)清session會話和(he)token令牌(pai)的區別，在keycloak中(zhong)，他們是(shi)不(bu)同的兩個概念(nian)，職責也不(bu)一樣。

session【session_state】

它被保存(cun)到瀏(liu)覽器(qi)的cookie中(zhong)，有4個會話屬性(xing)，這(zhe)主要基于高低版本瀏(liu)覽器(qi)和(he)記住我功(gong)能考慮而(er)設計(ji)的

按著(zhu)kc系統(tong)獲(huo)取(qu)會話的(de)優先級，他(ta)們(men)分別(bie)是：【帶_legacy是為(wei)了適應不支持samesite屬(shu)性的(de)瀏覽器】

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里已經有了用戶信息，并且添加了當前會話信息；而傳統的而自解釋
的(de)token，往(wang)往(wang)需要把它(ta)與(yu)當前用戶(hu)作一個對應關系，緩存(cun)起來，這(zhe)點(dian)kc的(de)jwt不(bu)需要存(cun)儲。

一 根據(ju)職責(ze)，設(she)置時(shi)長

• 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":"//kc.com/auth/realms/fabao/protocol/openid-connect",
    "account-service":"//kc.com/auth/realms/fabao/account",
    "tokens-not-before":1670507855
}

三 refresh_token使用方式
refresh_token去(qu)刷新token的方式(shi)方法，往往爭論(lun)不休，業界的做法也是多種多樣，其(qi)中使(shi)用最多的，還是在前(qian)端(duan)添加輪訓操作，定時去(qu)通過refresh_token去(qu)換新的access_token

  refreshToken() {
      this.refreshTime = setInterval(() => {
        checkToken(this.refreshLock, this.$store)
      }, 60000)
    }