OIDC redirect loop on cold browser: "No sqlpage_oidc_state_* cookie found" (variant of #1014)

[rodrigozayasreyes]

Introduction

This is a variant of the closed issue #1014 ("when two login flows start at the same time, both end up in an infinite redirection loop"). The fix in PR #1022 addressed the case where the state cookie exists but the CSRF token does not match ("Invalid CSRF token"). However, on SQLPage v0.44.1 we still observe a brief redirect loop on cold browser start, but with a different error: the state cookie is entirely absent ("No sqlpage_oidc_state_* cookie found").

To Reproduce

1. Close the browser completely (no session cookies)
2. Open the browser and navigate to https:///index.sql
3. The browser briefly displays the "this page has been redirected multiple times" (ERR_TOO_MANY_REDIRECTS) message
4. After ~1–2 seconds, the page loads correctly
5. On subsequent refreshes (without closing the browser), no message appears

Actual behavior

Brief redirect loop (~1–2 seconds) on every cold browser start. The loop self-resolves thanks to MAX_OIDC_REDIRECTS = 3, but the user sees a confusing browser-level error message.

Expected behavior

Login should complete without a visible redirect loop on the first cold browser visit.

Version information

• SQLPage version: v0.44.1
• OS: Debian
• Database: PostgreSQL
• Database version: 13
• OIDC provider: Microsoft Entra ID (Azure AD) v2.0
• Reverse proxy: Apache 2.4 with SSL termination, ProxyPreserveHost On, X-Forwarded-Proto: https
• sqlpage.json:
  {
  "listen_on": "127.0.0.1:9090",
  "host": "",
  "web_root": "./www",
  "oidc_client_id": "",
  "oidc_client_secret": "",
  "oidc_issuer_url": "https://login.microsoftonline.com//v2.0"
  }
• Azure AD app registration:
• Redirect URI: https:///sqlpage/oidc_callback (no trailing slash)
• No logout URL configured
• No responseMode in manifest (defaults to query)
• oidc_scopes not explicitly set (default: openid email profile)

Additional context

Server Logs

Captured with journalctl -u sqlpage --since "1 hour ago" | grep oidc. Tokens redacted ().
jul 07 16:00:19 INFO sqlpage[...] OIDC redirect URL for : https:///sqlpage/oidc_callback
jul 07 16:00:19 INFO sqlpage[...] Redirecting to / after a successful login
jul 07 16:00:19 INFO sqlpage[...] 127.0.0.1 "GET /sqlpage/oidc_callback?code=&state=8FsztBELZz-ekYCxRRClpw&session_state= HTTP/1.1" 303 14

jul 07 16:00:20 ERROR sqlpage[...] Failed to process OIDC callback (attempt 0). Refreshing oidc provider metadata, then redirecting to home page: No sqlpage_oidc_state_8FsztBELZz-ekYCxRRClpw cookie found
jul 07 16:00:20 INFO sqlpage[...] 127.0.0.1 "GET /sqlpage/oidc_callback?code=&state=8FsztBELZz-ekYCxRRClpw&session_state= HTTP/1.1" 303 14

jul 07 16:00:20 INFO sqlpage[...] Redirecting to / after a successful login
jul 07 16:00:20 INFO sqlpage[...] 127.0.0.1 "GET /sqlpage/oidc_callback?code=&state=xOfNdUdviWCxkjPK-UA2fA&session_state= HTTP/1.1" 303 14

jul 07 16:00:21 ERROR sqlpage[...] Failed to process OIDC callback (attempt 0): No sqlpage_oidc_state_8FsztBELZz-ekYCxRRClpw cookie found
jul 07 16:00:21 INFO sqlpage[...] 127.0.0.1 "GET /sqlpage/oidc_callback?code=&state=8FsztBELZz-ekYCxRRClpw&session_state= HTTP/1.1" 303 14

jul 07 16:00:22 INFO sqlpage[...] Redirecting to / after a successful login
jul 07 16:00:22 INFO sqlpage[...] 127.0.0.1 "GET /sqlpage/oidc_callback?code=&state=kggvpGsT3Y-EQB_uVKOoGQ&session_state= HTTP/1.1" 303 14

jul 07 16:00:22 ERROR sqlpage[...] Failed to process OIDC callback (attempt 0): No sqlpage_oidc_state_8FsztBELZz-ekYCxRRClpw cookie found
jul 07 16:00:24 INFO sqlpage[...] Redirecting to / after a successful login
jul 07 16:00:26 ERROR sqlpage[...] Failed to process OIDC callback (attempt 0): No sqlpage_oidc_state_8FsztBELZz-ekYCxRRClpw cookie found
jul 07 16:00:27 INFO sqlpage[...] Redirecting to / after a successful login

[rodrigozayasreyes]

Analysis

Two key observations from the logs:

1. The same state=8FsztBELZz-ekYCxRRClpw appears in all failed callbacks, while successful callbacks have a different state each time. This indicates the browser is replaying the callback with the original state in parallel requests, not triggering a retry flow that would generate a new state.
2. The error message is "No sqlpage_oidc_state_ cookie found" — not "Invalid CSRF token" (the error addressed by PR Refactor OIDC request handling to streamline callback processing and remove redundant code. Simplify the handling of authenticated user info and improve error logging for OIDC callback parameters. #1022). The state cookie is entirely absent, not present-but-mismatched.

Hypothesis

On cold browser start, Chrome fires multiple parallel navigations (main page, preload, favicon, preconnect, etc.) that all hit the protected path. The OIDC middleware generates a new state cookie for each, but only one survives to the callback. When the browser follows the Microsoft redirect back to the callback (using the URL Microsoft generated, which embeds the first request's state), the corresponding sqlpage_oidc_state_ cookie has been either:

• overwritten by another concurrent login flow (the case fixed by PR Refactor OIDC request handling to streamline callback processing and remove redundant code. Simplify the handling of authenticated user info and improve error logging for OIDC callback parameters. #1022), OR
• consumed/removed by a parallel callback that succeeded first, OR
• never stored because the redirect chain that set it was longer than the browser's tolerance for Set-Cookie in a redirect chain.

Why does it only happen on cold start?

After the first successful login, the sqlpage_auth and sqlpage_oidc_nonce cookies persist for 7 days, so subsequent refreshes proceed directly without touching the OIDC flow. The race condition only triggers when multiple requests hit the protected path with no existing session — i.e., on a freshly opened browser with no cached cookies.

Comparison with issue #1014

	#1014	This report
SQLPage version	<0.44 (Sept 2025)	v0.44.1
Error	Invalid CSRF token: <state>	No sqlpage_oidc_state_<state> cookie found
State cookie state	Present but mismatched	Entirely absent
Repair PR	#1022 (merged Sept 19, 2025)	Not addressed
Loop duration	Infinite (no cap)	Capped by MAX_OIDC_REDIRECTS = 3, resolves in ~1–2s

The redirect-count cap added as part of PR #1022 prevents the loop from being infinite, but the underlying race condition (browser replaying a callback with an absent state cookie) still produces a visible "redirected multiple times" message on the user's screen.

Suggested direction

Possible mitigations:

• Use a shorter-lived or non-cookie-bound state store (e.g., server-side state table keyed by state rather than cookie-by-name).
• Bind the state cookie so that multiple concurrent login flows each retain their own cookie (the PR Refactor OIDC request handling to streamline callback processing and remove redundant code. Simplify the handling of authenticated user info and improve error logging for OIDC callback parameters. #1022 eviction logic partially handles this, but the chrome-side Set-Cookie ordering in a redirect chain may still drop one).
• Or instruct the browser not to issue parallel protected-path requests during the login redirect (hard to enforce).