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时，这个会话将被回收，同时这个用户在前端也会从新去登录页认证