fix(signin): two independent causes of failed Ministry Platform sign-in

[chriskehayias]

Sign-in was failing with /auth-error?error=unable_to_get_user_info. There turned out to be two independent bugs behind that one symptom. Both are fixed here and verified against a live Ministry Platform sign-in.

1. MP never echoes the id_token nonce — the actual blocker

better-auth 1.7 enables nonce binding automatically for any provider whose discovery document yields an id_token config (requiresIdTokenNonce), sends a nonce on the authorize request, and then requires the claim back. nonceMatches() returns false when the claim is absent. MP omits it, so verification failed deterministically:

Provider "ministry-platform": id_token failed verification against the
discovery JWKS or expected nonce

Confirmed by decoding a real MP id_token rather than by inference — kid, alg, iss, aud all matched the discovered values exactly; only nonce was missing.

Fix: disableIdTokenNonceBinding: true. Signature, issuer and audience are still verified against MP's JWKS. What's given up is binding the token to this particular authorization request; the residual risk is mitigated by the state cookie check that still runs and by this being a confidential client exchanging the code with a secret. PKCE (F8) would narrow it further.

Why it looked intermittent

Inverted from the obvious reading: sign-in succeeded only when the boot-time discovery fetch had failed, because that leaves the id_token config undefined and skips verification entirely. A working discovery meant a broken sign-in. That inversion is what made this hard to pin down.

2. /signin started two OAuth flows per attempt

Every attempt fired two POST /api/auth/sign-in/social. The guard was a useState flag read inside the getSession() callback with the state in the effect's dep array; StrictMode double-invokes effects in dev, both runs reached the async callback having captured false, and both called signIn.social(). A state flag cannot close that window.

Each call mints its own state + nonce and overwrites the single oauth_state cookie the callback validates against, so the flows raced. Fix: a ref, checked and set synchronously before the first await.

This was a real bug but not the cause of the error above — the error reproduces in a production build, where StrictMode does not double-invoke and only one flow is ever started. Worth being explicit, because fixing it first made it look solved.

Ruled out with evidence

• JWKS rotation / multi-node signer — six probes returned one key, same kid
• Signature, issuer, audience, algorithm — all confirmed matching from the decoded token
• Clock skew — measured ~85–160 ms. The id_token nbf is checked with jose's zero clock tolerance, so this does bite occasionally at an integer-second boundary and is a genuine second-order fragility — but it cannot explain a deterministic failure. The dev machine's Windows Time service was stopped; syncing it removed the variable.

Tests

• New StrictMode test asserting exactly one signIn.social() and one getSession(). Verified it fails against the old implementation, so it pins the regression rather than just passing.
• Corrected "does not start a second sign-in when the effect re-runs", which asserted getSession was called twice — it had encoded the broken behavior as correct.
• 979 tests / 56 files passing; lint and tsc --noEmit clean.

Follow-up (not in this PR)

One transient discovery failure at boot disables the provider for the life of the process, with no retry — observed once during this investigation. That's a production robustness risk worth its own ticket.

Documented in .claude/references/auth.md.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!