Unexpected "Update Account" form after login with Keycloak 26 behind reverse proxy

Hi,

I’ve just set up Keycloak 26.3 in a Docker container on a VM. The container starts correctly without errors and is accessible through an Nginx reverse proxy configured as follows:

server {
listen 443 ssl;
server_name keycloak-kc01.mondomaine.fr;

ssl_certificate /etc/nginx/certs/fullchain.pem;
ssl_certificate_key /etc/nginx/certs/privkey.pem;

location / {
    proxy_pass http://keycloak-kc01:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Port 443;
    proxy_set_header X-Forwarded-Host $host;
}

}
My Keycloak Docker service is configured with environment variables for proxy, cookies, and cluster (JGroups/ISPN). The relevant variables include:

yaml
Copier le code
KC_HTTP_ENABLED: “true”
KC_PROXY_HEADERS: xforwarded
KC_PROXY: edge
KC_COOKIE_SECURE: “true”
KC_COOKIE_SAMESITE: “None”
KC_HOSTNAME: keycloak-kc01.mondomaine.fr
I created a client using OpenID Connect and a frontend JS application to test authentication:

ts
Copier le code
const keycloakConfig: KeycloakOptions = {
config: {
url: ‘https://keycloak-kc01.mondomaine.fr’,
realm: ‘info-adm53’,
clientId: ‘sensibilisation-ia-application’
},
initOptions: {
onLoad: ‘login-required’,
checkLoginIframe: false
},
bearerExcludedUrls: [‘/assets’]
};
The login flow works fine: I’m redirected to Keycloak login, credentials are accepted. However, after login I’m unexpectedly redirected to the “Update Account” form where I must enter email, first name, and last name.

Previously, I had a “cookie not found” issue after login, which I believe was resolved by setting:

yaml
Copier le code
KC_COOKIE_SECURE: “true”
KC_COOKIE_SAMESITE: “None”
I don’t understand why this “Update Account” form appears. I have reviewed all client settings and realm configurations in the admin console but cannot identify the cause.

Has anyone experienced this behavior on Keycloak 26 with Docker behind a reverse proxy? Could it be related to cookies, proxy settings, or some new behavior in Keycloak 26?

Thanks in advance for any guidance.

The “Update Account” action is IMHO not related to any cookies and/or proxy settings. If a user does not have the required fields (by default: username, email, firstname, lastname) filled, Keycloak will ask the user to provide this information upon login.
You didn’t tell us, if you created the user with just a username, or if you also provided all properties when created.
The attribute requirements can be changed in the “User profile” settings in your realm.


Besides that: KC_PROXY: edge is no more valid, you can remove this from your config.

I’ve set up the LDAP connection, and all my users have been successfully synchronized — I can see them listed in the admin interface. The test user I selected also has all the necessary information correctly populated in the LDAP.

Sorry for overlooking that earlier.

If the user you use to authenticate with looks good in admin ui (has the 4 mentioned properties available), then I don’t know just from your description, what possibly can be wrong, sorry.

Thank for your help Mr Keycloak :slight_smile:

I found the source of my “profile update” issue. It comes from a “required” field in the Keycloak admin console. However, now I am facing a new issue. I set up an HAProxy server for load balancing between the two Keycloak instances, and the URL for accessing the service is “identity-test.mydomaine”. Here’s my HAProxy configuration:

frontend https_front
    bind *:443 ssl crt /etc/ssl/haproxy/san-agglo-mydomain.pem
    mode http
    option forwardfor
    http-request set-header X-Forwarded-Proto https
    http-request set-header Host %[req.hdr(host)]
    # Add:
    http-request set-header X-Forwarded-Port 443
    http-request set-header X-Forwarded-Host %[req.hdr(host)]

    log-format "%ci:%cp [%tr] %ft %b/%s %TR/%Tw/%Tc/%Tr/%Ta %ST %B %CC %CS %tsc %ac/%fc/%bc/%sc/%rc %sq/%bq %hr %hs %{+Q}r %sslv %sslc %[ssl_fc_cipherlist_str]"

    acl host_identity_test hdr(host) -i identity-test.mydomaine.fr

    use_backend kc_test_backend if host_identity_test

backend kc_test_backend
    balance roundrobin
    option httpchk
    http-check send meth GET uri /realms/master ver HTTP/1.1 hdr Host identity-test.mydomaine.fr
    server kc01 keycloak-kc01.mydomain.fr:443 ssl verify none check observe layer4 weight 100
    server kc02 keycloak-kc02.mydomain.fr:443 ssl verify none check observe layer4 weight 100
    http-request set-header Host identity-test.mydomaine.fr

I changed the hostname in both Keycloak containers to reference “identity-test.mydomaine”, but now I seem to have an issue with cookies or something else that I can’t identify. When I launch a client, I am correctly redirected to the authentication page on identity-test.mydomaine , and once I enter my credentials, I am redirected back to my application (but with a blank page error) along with the following error in Docker logs:

2025-09-22 09:20:38,042 WARN  [org.keycloak.protocol.oidc.utils.OAuth2CodeParser] (executor-thread-3) Code '0d6fc5ba-a8c4-4ea9-ab95-67413d9c5c1c' already used for userSession 'f4e07d33-08f6-4ff1-acff-c3151ee04619' and client '8ef0ecf9-7271-4d63-86b6-381cef7ad5a3'.
2025-09-22 09:20:38,044 WARN  [org.keycloak.events] (executor-thread-3) type="CODE_TO_TOKEN_ERROR", realmId="adfe163c-5343-43c5-8b4f-c926a4fee725", realmName="info-adm53", clientId="sensibilisation-ia-application", userId="null", sessionId="f4e07d33-08f6-4ff1-acff-c3151ee04619", ipAddress="192.168.148.25", error="invalid_code", grant_type="authorization_code", code_id="f4e07d33-08f6-4ff1-acff-c3151ee04619", client_auth_method="client-secret".

It’s not easy to explain my issue, but I’m not sure I’m doing things correctly when setting up the Keycloak cluster. Can someone assist me with this?

As I suspected.

Then please open a new issue if it is another topic. Thanks.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.