fix(sso): keep the OIDC authorize request when Kerberos SSO fails

[alghanim]

When Kerberos SSO fails during an OIDC login, the browser ends up at the client's redirect_uri with ?error=<message> and no state. Every OIDC client treats a callback without its state as a CSRF attempt, so the user sees the client's state/CSRF error instead of the real reason, and never gets the chance to fall back to their AD password. A failed password attempt behaves correctly: it returns to SimpleAuth's login page with the whole request (H13).

This is the follow-up named in #72. The two PRs touch different functions and merge cleanly in either order.

Two hops dropped the authorize request

oidcAuthzRequest documents the Kerberos SSO link as a hop that must carry the request. The way back out of /login/sso did not:

1. The Negotiate fallback. A browser that can't answer the 401 challenge (a machine not on the domain, or a browser not allowed to negotiate with the host) follows the page's meta-refresh. That retry URL kept only redirect_uri. client_id, oidc, state, nonce and the PKCE challenge were lost, so the retry resolved the default app:
   • an app whose redirect_uri is only in its own allowlist got a dead-end 400 redirect_uri not allowed;
   • an OIDC attempt quietly continued as a non-OIDC one.
2. The failure redirect. All 15 failure exits in handleSSOLogin called redirectToLoginError, which bounces to the client's redirect_uri?error=… without state.

Change

• The retry URL is built from the same typed oidcAuthzRequest allowlist, plus oidc and sso_attempt. Every value is percent-encoded by url.Values.Encode, so the meta-refresh still contains no raw request text, and the existing html.EscapeString stays as defence in depth.
• A new ssoLoginError routes failures. An OIDC attempt (oidc=1) goes through renderOIDCLoginError, exactly like a failed password: back to SimpleAuth's authorize page with the error banner and the whole request. The __sso_attempted cookie and the error banner already stop auto-SSO from looping. Non-OIDC (hosted) flows keep redirectToLoginError and its ?error= redirect, now for the right app.

Verification

Unit tests (sso_failure_test.go). All four fail on master and pass here:

• the Negotiate retry keeps every authorize parameter, plus oidc and sso_attempt=1;
• an OIDC failure returns to the authorize page with state, nonce and PKCE, never to the client's callback;
• the Kerberos-not-configured failure does the same;
• the hosted flow still redirects an app-allowlisted redirect_uri with ?error=. Before, it got 400 from the default app.

The existing OIDC/PKCE/H13 tests are unchanged and pass. The full go test ./... is green, and go vet and gofmt are clean.

End to end: a Samba AD DC behind nginx with TLS, browser flows driven with one cookie jar:

flow	before	after
browser without Kerberos clicks SSO	app callback ?error=SSO authentication failed…, no state	SimpleAuth login page showing the reason → AD password → callback with code + state
Kerberos OK, user not assigned to the app	app callback ?error=Access denied…, no state	login page shows "Access denied: not assigned to this app"
Kerberos OK, assigned	callback with code + state	unchanged

Assignment is still enforced where it was: a code issued after the password fallback to an unassigned user is refused at the token endpoint (issueOIDCTokens → resolveTokenRoles → 403 access_denied).

🤖 Generated with Claude Code