2 posts tagged with "cookies"

"Restart login cookie not found. It may have expired; it may have been deleted or cookies are disabled in your browser." Keycloak shows this on a dead-end HTTP 400 page, and the message is more confident than it should be. It means exactly one thing: the request arrived with no KC_RESTART cookie at all. Not a stale one, not a rejected one. None. That cookie has no expiry to run out, so "it may have expired" is the one explanation that is never true. A rejected cookie produces a different message. And the page tells the user to "Click Back to Application", which on a default client renders no link to click.

Here is what the cookie is for, how to tell in one log line which failure you have, and the one client field that turns the dead end into a recoverable page.

A Keycloak infinite redirect loop at login almost always means one thing: a cookie Keycloak set on the way to the login page did not come back on the way out of it. Keycloak has no session to resume, so it starts the flow again, and the browser bounces between your application and /protocol/openid-connect/auth until it gives up.

The reason this is so common is in the Set-Cookie headers. Keycloak 26.8.0 marks every cookie in the login flow Secure; SameSite=None, unconditionally — there is no setting that relaxes it. A browser will not store a Secure cookie that arrives over plain http://, and it will not store SameSite=None without Secure. So the loop is usually not an OIDC problem at all. It is a transport problem that the OIDC layer reports as a lost session.