keycloak存到cookie中的值

• AUTH_SESSION_ID
• KEYCLOAK_IDENTITY
• KEYCLOAK_SESSION

AUTH_SESSION_ID

用户的当前session_state，它是会话级的，关闭浏览器就没了

KEYCLOAK_IDENTITY

它是用户跨端登录的基础，它也是一个jwt串，解析后是这样的结果，用户在当前端没有登录时，会跳到kc认证页，当发现cookie里的kc域下有这个
KEYCLOAK_IDENTITY
，会使用这个
session_state
进行认证，没有这个键，KC认证不能完成。

{
    "exp": 1682659005,
    "iat": 1680067005,
    "jti": "d655a51e-f363-43cf-9f3e-1be8c4f7f082",
    "iss": "https://finalcas.pkulaw.com/auth/realms/fabao",
    "sub": "347c9e9e-076c-45e3-be74-c482fffcc6e5",
    "typ": "Serialized-ID",
    "session_state": "4b020044-d273-41c6-9cea-c9ea1b0814f7",
    "state_checker": "SGniuhvr-FbQ7aznFTiTDIi2Gt4CKev7DI3vLNvJufo"
}

注意：如果浏览器的cookie里的KEYCLOAK_IDENTITY丢失了，会导致KC出现无法登录的问题，解决方法只能是清除浏览器里的AUTH_SESSION_ID和KEYCLOAK_SESSION，注意还有后缀为LEGACY的键值.

KEYCLOAK_SESSION

当你可算让KC记住你的登录状态，这时KC会在cookie中生成
KEYCLOAK_SESSION
，它的值默认与AUTH_SESSION_ID相同，当是一个包含过期时间的cookie，浏览器关闭后它依然保持，直到你在KC
记住我
中配置的过期时间。

假设还有第2个、第3个应用，在keycloak的相同的realm中注册了各自的client，我们在访问第2个、第3个应用的时候，也会跳转到keycloak登录页面（带上各自的client_id, redirect_url），但是就像上面的现象一样，我们的keycloak登录页对应的domain/path中有那3个cookie值AUTH_SESSION_ID，KEYCLOAK_IDENTITY和KEYCLOAK_SESSION， 这样就会自动跳转到我们应用的界面，无需填写keycloak登录的账号密码，并且能够返回授权码code，这就算登录成功了，登录成功之后，后续的操作就是我们再利用这个授权码code和client_secret访问keycloak去获取access token，这就是Oauth2.0的授权码模式。

sesssion_state

以上三个被存储在客户端浏览器里的键值（ AUTH_SESSION_ID, KEYCLOAK_IDENTITY,KEYCLOAK_SESSION）都有对session_state的存储，只不过，我们存储的有效期不同，AUTH_SESSION_ID是会话级，后两个是与KC后台配置的
记住我
中的refresh_token有效期相同的，即SSO Session Idle， SSO Session Max，Client Session Idle，Client Session Max四个配置，谁小使用谁。

• 当session_state达到这个refresh_token的超时时间+access_token超时时间后，它会被删除
• 当用户进行登出操作后，它会被删除
• 如下配置，用户在
  3+2
  分钟后PM 02:22:17时，它的 会话将被删除（回收）
  
  
  在02：22：17 PM时，这个会话将被回收，同时这个用户在前端也会从新去登录页认证