SSO login loops: support troubleshooting steps

TL;DR

A login loop means the app and the identity provider keep handing the user back and forth without ever creating a session. Start with a clean incognito test to rule out stale cookies, then check the three usual suspects: clock skew, a mismatched reply URL or certificate, and a user the provider recognizes but the app does not. Most loops are one of those three, not a broken integration.

The query

SSO login loops: support troubleshooting steps

Use this when

• Users report being bounced between the app and Okta, Entra ID, Google Workspace, or another identity provider
• "Too many redirects" appears during login
• Login works for some users but loops for others
• SSO just rolled out and a whole team is stuck

Not for

• Password reset requests
• MFA enrollment or lost authenticator apps
• Deciding which identity provider to buy or how to set up SSO the first time
• Account provisioning and deprovisioning policy

Steps

1. Reproduce in a clean browser session

Have the user try in incognito or a different browser. If the loop disappears, it is stale session cookies on their normal browser, not your SSO config.

Expected output: you know whether the problem is the user's browser or your side.

2. Capture where the loop hands off

Ask the user to note the URL bar as it cycles: does it bounce between your app and the provider, or stay inside the provider? A bounce between the two means the app rejected the provider response. A loop inside the provider means the provider never finished authenticating.

Expected output: you know which side to investigate first.

3. Check the three usual suspects on your side

Clock skew: if your server clock is more than a few minutes off, signed assertions fail validation. Reply URL mismatch: the reply URL in your app must match what is registered in the provider exactly, including trailing slashes. Expired or rotated certificate: confirm the signing cert in the provider matches the one your app trusts.

Expected output: one of the three is confirmed or ruled out in about ten minutes.

4. Verify the user exists and is assigned in the provider

With just-in-time provisioning off, a user the provider authenticates but the app has no record of will bounce forever. Check the user is assigned to the app in the provider admin console.

Expected output: assignment confirmed, or you found the missing assignment.

5. Read the login error the app logged

The app almost always logs why it rejected the response. Look for the login attempt in your logs around the user's timestamp and read the actual error instead of guessing.

Expected output: the log line names the cause, and you can fix it or escalate with evidence.

Template: what to ask the user

Thanks for reporting this, [Name]. A few quick questions so I can
pinpoint the loop:

1. Which identity provider do you sign in with (Okta, Entra ID, Google)?
2. Does it loop in an incognito window too?
3. What time did it last happen (so I can check our logs)?
4. Are any teammates hitting the same thing, or just you?

Variant phrasings

sso keeps redirecting me in circles

Same steps. The incognito test in step 1 resolves about half of these tickets.

login loops after entering credentials

This phrasing usually means the provider authenticated fine and the app rejected the response. Start at step 3.

too many redirects on sso login

Check the reply URL first. A mismatch there is the most common cause of the browser redirect error.

Why it happens

SSO is a handshake with no memory: the app redirects to the provider, the provider sends back a signed response, the app validates it and creates a session. If validation fails for any reason, the app does the only thing it knows, redirect again, and the provider happily sends another response. Neither side errors out visibly, so the user sees an infinite loop instead of an error message.

Edge cases

• Multiple provider tenants: a user authenticating against the wrong tenant gets a valid response the app cannot map. Check the tenant or domain.
• Deep-link login: bookmarked URLs that skip the first redirect can start the flow mid-handshake. Have them log in from the homepage.
• Cookie-blocking browsers: some privacy settings block the session cookie the app sets after validation, so the loop restarts every time. Incognito with default settings usually works.
• Recently rotated signing certs: the app trusts the old cert until you update it. This breaks everyone at once, which is actually the easy diagnosis.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_33s7hSAPr9AhcWBQnQmAsQ