Keycloak的SSO功能与cookie的关系

很早以前就开始使用keycloak了，也知道keycloak的SSO功能是与其存储在cookie中的Session信息有关系，但是一直没有仔细研究过，今天跟同事讨论keycloak logout的过程中，一起研究了一下cookie中到底存了哪些Keycloak session信息，以及其起到的作用。

首先输入我们应用的地址，例如http://localhost:4200/，因为配置了keycloak，会自动跳转到keycloak登录页面，其Path为/auth/realms/master/

这个时候我们看cookie信息，发现cookie中添加了两个新项, KC_RESTART与AUTH_SESSION_ID, 并且其Path为 /auth/realms/master/，这里的Domain信息是keycloak的地址

然后我们登录，登录成功之后会跳转到我们的应用程序。

然后我们进入到Keycloak server查看信息，发现多了一项session信息，Keycloak server会管理这个session。

此时再看cookie信息，发现之前的两项没了，keycloakRefreshToken与keycloakToken是应用程序自己新加的，Domain信息是我们前端应用程序自己的地址（虽然跟前面的一致，但是这个要看应用程序与keycloak是否部署到同一个server上，不然其Domain也是不同的），但是其Path变成了应用程序自己的Path，不再一致，不再是/auth/realms/master/。

怎么回事呢？ 难道之前的cookie信息KC_RESTART与AUTH_SESSION_ID被删掉了？其实不是的，应用程序中只能看到与自己相同Domain与Path的cookie信息，keycloak 登录界面的Domain与Path与应用程序的Domain与Path是不同的，所以跳转到应用程序后，不能够再看到keycloak登录界面产生的cookie信息。

想要看到全部的cookie，可以进入浏览器的cookie管理页面，这里管理所有的cookie信息。

加上一开始的AUTH_SESSION_ID(KC_RESTART已经被删除)，我们发现又添加了KEYCLOAK_IDENTITY和KEYCLOAK_SESSION两项，现在一共是3项。

• AUTH_SESSION_ID: 2cc5bcb9-32aa-473e-a792-02df17300426.cctf-cluster-control-01
• KEYCLOAK_IDENTITY: eyJhbGciOiJIUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJhZmVkNGNkMy1iNjhmLTRhOTQtYWMxZC1lMmVhMTRjNGZkYTYifQ.eyJqdGkiOiJlM2I3NjkwNy1kNWEyLTRkNDUtYmFmMy0wZTc3NzMxZjNhMjMiLCJleHAiOjE2MDkyNTEyNTIsIm5iZiI6MCwiaWF0IjoxNjA5MjE1MjUyLCJpc3MiOiJodHRwczovLzEwLjc2LjguMTMwOjg4NDMvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiNjg1Y2NkMTgtMTBhMS00ZjhmLTg3ZGUtOWUxMmY1ODlkOTQ5IiwidHlwIjoiU2VyaWFsaXplZC1JRCIsImF1dGhfdGltZSI6MCwic2Vzc2lvbl9zdGF0ZSI6IjJjYzViY2I5LTMyYWEtNDczZS1hNzkyLTAyZGYxNzMwMDQyNiIsInN0YXRlX2NoZWNrZXIiOiJaT0hubmhSQ3VoODNxSW5yYkM1Ty10QUxoUjEycVExSjBobUhjWUhtYmlzIn0.c3Vk8z0RJTIEPOciWG3wPTTIW5RWGkMQlEPTzSflMMo
• KEYCLOAK_SESSION: master/685ccd18-10a1-4f8f-87de-9e12f589d949/2cc5bcb9-32aa-473e-a792-02df17300426

然后关闭应用页面，在网站中输入keycloak登录地址（应用地址也是可以的），keycloak登录地址中的参数，要使用在keycloak中注册应用时的client_id和重定向地址redirect_uri：https://x.xxx.xxx.xxx:8843/auth/realms/master/protocol/openid-connect/auth?redirect_uri=https://xxx.xxx.xxx.xxx/cctf/&client_id=cctf-frontend-client&response_type=code&scope=openid

发现能够直接跳转到应用页面，不需要再跳转到keycloak登录页面并输入账号和密码，打开调试页面，发现上面的请求中带上了cookie中的信息AUTH_SESSION_ID，KEYCLOAK_IDENTITY和KEYCLOAK_SESSION

那么到底是哪个key起到了SSO的作用呢？只把AUTH_SESSION_ID清空，然后重新登录，输入https://x.xxx.xxx.xxx:8843/auth/realms/master/protocol/openid-connect/auth?redirect_uri=https://xxx.xxx.xxx.xxx/cctf/&client_id=cctf-frontend-client&response_type=code&scope=openid，发现不需要登录，直接进入应用页面，SSO仍然起作用；重新登录，只删除KEYCLOAK_SESSION，又试了一次，SSO仍然起作用；重新登录，只把KEYCLOAK_IDENTITY删除，SSO终于失效了

总结：

所以，只要从cookie中删除KEYCLOAK_IDENTITY的值，那么SSO就会失效。

我曾经尝试在应用界面中，使用java script将KEYCLOAK_IDENTITY置空，但是发现不起作用，原因是，应用程序只能操作与自己Domain与Path都相同的cookie，不符合这个条件的cookie信息是无法处理的，置空操作只会新添加一个内容为空的KEYCLOAK_IDENTITY，其Path为本应用的/cctf，无法操作keycloak domain/path 中的KEYCLOAK_IDENTITY

那么是如何实现SSO的呢？

假设还有第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的授权码模式。