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