如何让Keycloak SSO的KEYCLOAK_SESSION Cookie仅对当前浏览器标签页有效

可行性结论 #

直接给KEYCLOAK_SESSION Cookie绑定tab_id的思路是可行的，但Keycloak原生不支持这个逻辑，得做定制化改造。

具体落地步骤 #

1. 前端生成并传递tab_id #

用户首次登录时，在前端页面生成唯一的标签页标识（比如用UUID，存在sessionStorage里——因为sessionStorage会在标签页关闭后自动销毁）。然后在向Keycloak发认证请求时，通过自定义参数（比如tab_id）把这个标识传过去。

2. Keycloak服务器端绑定tab_id到会话 #

编写Keycloak的Authenticator SPI扩展，在用户认证成功、创建KEYCLOAK_SESSION的时候，把传过来的tab_id存到Keycloak的会话属性里。同时可以调整KEYCLOAK_SESSION Cookie的生成逻辑，或者在会话里单独存储tab_id的校验规则。

3. 拦截认证请求，校验tab_id匹配度 #

编写EventListener SPI扩展，每次客户端发起SSO认证（比如静默认证、跳转认证）时，从请求里提取当前的tab_id：

• 如果请求里没带tab_id，直接拒绝，强制重新登录。
• 如果tab_id和会话里存储的不匹配，直接销毁现有KEYCLOAK_SESSION，让用户重新登录。

4. 前端配合维护tab_id #

每个Web UI客户端初始化时，先检查sessionStorage里有没有tab_id：

• 没有的话就生成新的存进去，发认证请求时带上。
• 有的话就直接在所有SSO相关请求里带上这个tab_id。
  这样关闭标签页后sessionStorage销毁，新标签页会生成新tab_id，自然触发重新登录。

额外注意点 #

• 部分浏览器的隐私模式可能影响sessionStorage的行为，要做兼容测试。
• SPI扩展要和Keycloak版本对应，升级Keycloak时得同步更新扩展代码。
• 每次认证都要校验tab_id，会增加服务器开销，得优化校验逻辑。
• 其实还有个更简单的替代方案：把KEYCLOAK_SESSION改成会话Cookie（不设置Max-Age或Expires）。之前安全团队觉得它不是会话Cookie，可能是因为Keycloak配置里开了持久化会话，检查下Cookie的配置，确保没设持久化过期时间，同时HttpOnly、Secure、SameSite这些安全属性配置正确。

内容的提问来源于stack exchange，提问作者Shane Rowatt