Repository navigation
sub(ject) in KEYCLOAK_SESSION cookie #23338
|
Hi everyone, thank you for maintaining Keycloak – it is really useful for us. I have a beginner question regarding privacy and the KEYCLOAK_SESSION cookie. I find it difficult to judge how easy it would be for attackers to track users long-term by accessing this cookie. As far as I can tell, our Keycloak instance stores a string in the KEYCLOAK_SESSION cookie which contains the sub(ject) / user ID of the session. The value stored in the cookie appears to have the pattern: "$realm/$sub/$session-id". Since the cookie’s attributes in our Keycloak instance allow, from my understanding, relatively broad access for attackers (SameSite=None and no httpOnly set), I was wondering if there is therefore currently a privacy risk related to this cookie? I know there are already efforts to enable more secure cookie configurations, but I am unsure if it is necessary to store a long-term user ID in this cookie at all. Can/Should we configure Keycloak so that the KEYCLOAK_SESSION cookie only contains a short-lived session ID? I probably misunderstand something about cookies or Keycloak so I would really appreciate your input. Thanks! |
Replies: 1 comment 1 reply
|
The Not quite sure what is your threat model. If you are considering XSS, then yes that can be used to read the cookie, but I'm not sure if a privacy risk from leaking a user-id in a cookie would be my main concern. XSS would be able to read/write requests and responses from your application for instance. It is true that having the user-id in the value doesn't look quite right especially since the value isn't used. The Related issue |
|
Thank you for your quick and informative reply! I realized in the meantime that I misunderstood which sites can access the cookie – so my threat model was wrong and the remaining threats would probably cause bigger problems, as you pointed out. Nevertheless it is useful to know that we are not using a "bad" configuration. |
The
KEYCLOAK_SESSIONcookie is largely used for OpenID Connect Session Management described at https://openid.net/specs/openid-connect-session-1_0.html where your application has an iframe to talk to the Keycloak iframe to determine if the user has logged out for instance.Not quite sure what is your threat model. If you are considering XSS, then yes that can be used to read the cookie, but I'm not sure if a privacy risk from leaking a user-id in a cookie would be my main concern. XSS would be able to read/write requests and responses from your application for instance. It is true that having the user-id in the value doesn't look quite right especially since the value isn't used.
The
KEYC…