Uploaded image for project: 'Keycloak'
  1. Keycloak
  2. KEYCLOAK-2352

Support sticky sessions



    • Feature Request
    • Status: Closed
    • Major
    • Resolution: Rejected
    • None
    • None
    • None
    • None


      Keycloak doesn't strictly require sticky sessions when used in combination with a load balancer, but it may improve performance. Looking at a typical usage scenario we'd have the following requests from the browser:

      • Open login page
      • Submit username/password
      • Open OTP page
      • Submit OTP
      • Redirect to client

      Followed by the following requests from the client (assuming OpenID Connect):

      • Client exchanges code for token
      • Client refreshes token N times

      All requests require various realm details as well as user details. The realm details is not a problem as it's assumed this will be cached on all nodes. The user details in this case would have to be loaded onto all nodes involved in processing the requests. With a round-robin load balancer this could quickly result in all nodes.

      A load balancer can be configured to use either a cookie or the source IP to send all requests to a specific node. There is not currently suitable cookie available so the only means currently is using the source IP address. This has two issues:

      • Requests from the browser and requests from the client won't be sent to the same node
      • All requests from one client is sent to the same node. This could result in one heavily used client sending all requests (for all users) to a single node, which could impact performance

      With that in mind the proposed solution is to add a session cookie that can be used for load balancer. The session cookie will be set when the user first visits the login page and it would contain a UUID. When the user session is first created (once authenticated) the user session id will be set to the UUID from the session cookie. Adapters would also be extended to include the session cookie. The adapters can retrieve the session id from the access token (session state field).

      One remaining issue which we don't have a solution for yet is when user sessions are stored in a distributed Infinispan cache we should make sure the user session is stored on the node where the request is made. Currently, user sessions are distributed by Infinispan outside of our control.


        Issue Links



              Unassigned Unassigned
              sthorger@redhat.com Stian Thorgersen
              2 Vote for this issue
              6 Start watching this issue