Users cannot stay signed in: work through the failure in this order

1. Does the user reach the provider and come back?

Start where the user first sees an error. If the provider's page shows a redirect mismatch, the failure is a string comparison between the address your app sent and the registered list; compare them character by character, using the callback matrix example as a format. If the provider shows an unverified-app or restricted-user message, it is a provider status, not a code fault. If the user returns to your app, move to step 2.

• Provider error naming the redirect: redirect address guide, then the fixed sign-in callback repair.
• Provider status or restriction: the provider console, not code.

2. Does your app accept the return?

If the user comes back to your callback and your app refuses, look at what the app remembered before the redirect: the state value and, where used, the code verifier. A missing value usually means the host changed between start and return, the cookie holding it was withheld, two attempts overlapped or the callback ran twice with a one-time code. A correct app rejects an altered or missing state, so the check must be fixed, not removed.

• Callback rejects the return: state and verifier guide.
• Same, with the host changing between start and return: compare hosts first.

3. Does the browser keep and return the session cookie?

If the app accepts the return and signs the user in, but the next page treats them as signed out, the cookie is being refused or not returned. Read the response that sets it in the browser developer tools and check Secure, SameSite, Domain, Path and expiry. A login that works locally and loops on the live domain points to step 4. A login that fails only when arriving from another site or an email link points to SameSite.

• Cookie not set at all, only on the live site: step 4.
• Cookie set but not returned: cookie attribute guide.

4. Does the app know it is on HTTPS?

Behind a proxy or load balancer, the app may receive plain HTTP and so refuse to set a Secure cookie or build http addresses. Check the framework setting that trusts forwarded protocol and host headers, trusting only your own proxy and making sure the proxy overwrites those headers. This is the least visible cause and often the one that changes only on the day the site moves host.

• Callback addresses start with http on an HTTPS site: this step.
• Client addresses in logs are always the proxy's address: this step.

5. Is the session found on the server?

If the cookie is returned and the user is still signed out, the server cannot find or read the session: more than one instance with sessions in memory, a secret that differs between instances, or a session that was replaced at login and lost its state. Separately, in apps that read user data through a database layer with row protection, a missing session at the data call produces empty lists rather than errors; check the data-access guide.

• Several app instances: one store and one secret.
• Signed in but lists are empty: the Supabase access guide, if that is your stack.

Which job fits, and what is not covered

A provider callback fault is the fixed sign-in callback repair (£195, untested, up to three environments). A session that is not kept is the login-session repair (from £295, untested). Both are paid only after the agreed test sign-in passes and you sign off. Several flows that must all work, with a check that stays, is the project to stabilise critical flows (from £3,500, quoted), and weekly checks afterwards are the monthly service (£395 a month, untested, no response-time guarantee). Not covered: provider reviews, single sign-on for business customers, merging duplicate accounts and security audits. Send the failing step and the redacted error in your first enquiry, never passwords, tokens or cookie values.