login redirect loop between the app and the identity provider after en

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

login redirect loop between the app and the identity provider after enabling SSO

TL;DR

The app bounces you to the identity provider, the provider sends you back, the app doesn't recognize the session, repeat. Almost always the session cookie isn't surviving the round trip: wrong SameSite or Secure attributes, a callback URL mismatch, or the app and provider disagreeing on the session. Fix the cookie first.

login redirect loop between the app and the identity provider after enabling SSO

Use this when

• Enabling SAML or OIDC produces an endless bounce between your app and the identity provider
• The loop starts immediately after SSO is turned on, with no error page
• The browser network log shows app to IdP to callback to app, repeating
• It works in one browser but loops in another

Not for this skill when

• Login fails with a visible error page (read the error instead)
• The identity provider itself rejects the credentials
• The loop happens at logout rather than login

Steps

1. Watch one loop in the browser network panel with "preserve log" on. Note the exact sequence: app to IdP, IdP POST back to the callback, app redirecting to IdP again.

Expected: you see the callback request returning a redirect instead of establishing a session.

2. Inspect the session cookie on the callback response. On HTTPS it must carry the Secure attribute, and SameSite must suit the flow (Lax usually works for top-level GET callbacks; None plus Secure for POST-back flows).

Expected: Set-Cookie present with the right attributes. If the cookie never appears, the app isn't persisting the session at all.

3. Compare the callback URL registered at the IdP with the one the app sends, character for character: scheme, host, port, trailing slash.

Expected: exact match. An http vs https or trailing-slash difference makes the IdP mint tokens for a callback the app doesn't trust.

4. Check clock skew between the app server and the IdP. SAML and OIDC both reject assertions outside a tight time window, which looks like a loop when the app retries:

date -u

Run it on the app server and compare to a known-good clock. Expected: within a minute. If not, fix NTP.

5. If the app sits behind a proxy, confirm it sees the original scheme (X-Forwarded-Proto) so it doesn't set cookies for http while serving https.

Expected: one clean login, session cookie present, no second trip to the IdP.

Variant: loop only in Safari or Firefox

Stricter cookie handling there; SameSite=None without Secure is rejected outright. Fix the attributes rather than blaming the browser.

Variant: loop after enabling force authentication at the IdP

The IdP never shows an existing session, so it always re-challenges. Relax the force-authn setting unless you truly need it on every login.

Variant: WordPress or Discourse SSO loops

Same cookie-first debugging, plugin settings second. Check the plugin's callback URL and cookie domain settings before anything else.

Why this happens

SSO is a two-hop dance that only works if the session established on the return hop sticks. Anything that drops the cookie, attribute mismatch, domain mismatch, the app clearing the session on the callback, restarts the dance from the top, and both sides happily loop forever.

Edge cases and pitfalls

• An ad blocker or privacy extension eating third-party cookies can cause loops no config change fixes; test in a clean profile.
• If the IdP session lifetime is shorter than the app's, users loop at re-auth; align the lifetimes.
• Log the SAML or OIDC error at the app before assuming it's the cookie; sometimes the IdP is rejecting the request and the app retries blindly.
• Sticky sessions matter: if the callback lands on a different app instance with in-memory sessions, the session is gone; use a shared session store.

Provenance

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

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

Thread query: login redirect loop between the app and the identity provider after enabling SSO

TL;DR: The app bounces you to the identity provider, the provider sends you back, the app doesn't recognize the session, repeat. Almost always the session cookie isn't surviving the round trip: wrong SameSite or Secure attributes, a callback URL mismatch, or the app and provider disagreeing on the session. Fix the cookie first.

Not specified by the original author.

TL;DR

A SAML login loop means authentication succeeds at the identity provider but Zendesk rejects the session and sends the agent back, usually because the NameID or email in the assertion does not match a Zendesk user, or the ACS URL the IdP posts to is wrong. Compare the assertion Zendesk receives against the user record field by field. The loop is a mismatch, not a mystery.

The query

zendesk "saml sso login loop" agents redirected after auth

Use this when

• Agents authenticate at the IdP then return to the login page
• SSO logins loop without an error message
• SSO worked and broke after a config change
• You are debugging Zendesk agent SSO

Not for

• Password-based agent logins
• End-user (help center) SSO
• Setting up an IdP from scratch
• Social login configuration

Steps

1. Capture the SAML assertion Zendesk receives

Use the IdP's sign-in logs or a SAML tracer to capture the assertion. Check the NameID format and value, the email attribute, and the audience and recipient fields. The loop hides in one of these.

Expected output: the full assertion with NameID, email, audience, and recipient visible.

2. Match the NameID to the Zendesk user

Zendesk matches the assertion to a user by the configured identifier, usually email. If the NameID is a persistent opaque id but Zendesk expects email, no user matches and the login bounces. Align the NameID format with what Zendesk is configured to match on.

Expected output: NameID format aligned with the Zendesk user-matching field.

3. Verify the ACS URL and entity ID

The IdP must post the response to Zendesk's exact ACS URL, and the entity ID must match. A trailing slash or http versus https difference breaks the handshake silently. Copy both values from Zendesk's SSO settings into the IdP.

Expected output: ACS URL and entity ID byte-identical on both sides.

4. Check the signing certificate

An expired or rotated IdP certificate makes Zendesk reject the assertion. Confirm the certificate in Zendesk matches the IdP's current signing certificate, and note the expiry date.

Expected output: current valid certificate installed on both sides.

5. Test IdP-initiated versus SP-initiated separately

One flow may work while the other loops. Test both, and standardize on the working one while you fix the other. RelayState handling differs between the flows and is a common loop source.

Expected output: both flows tested, working flow identified.

Template: the checklist

Zendesk SAML login loop:
[ ] Assertion captured: NameID, email, audience, recipient checked
[ ] NameID format matches Zendesk user-matching configuration
[ ] ACS URL and entity ID byte-identical on both sides
[ ] Signing certificate current and matching
[ ] IdP-initiated and SP-initiated flows tested separately

Variant phrasings

zendesk sso keeps redirecting to login

Steps 1 and 2. Capture the assertion, match the user.

saml assertion rejected zendesk

Steps 3 and 4. ACS URL and certificate.

zendesk sso worked then broke

Step 4 first. Certificate rotation is the usual suspect.

Why it happens

SAML is a multi-party handshake where every field must agree: IdP configuration, Zendesk configuration, and the user record. A change on any side (cert rotation, email change, IdP upgrade) breaks the agreement, and the failure mode is a redirect loop rather than an error page because each side thinks the other should proceed.

Edge cases

• Email changes: a user whose email changed at the IdP no longer matches their Zendesk record. Update one side.
• Multiple Zendesk instances: the IdP app must target the right instance's ACS URL. Staging and production configs get swapped.
• Clock skew: assertions have a validity window. Severe skew between IdP and Zendesk rejects valid assertions.
• Just-in-time provisioning: if enabled, a mismatch creates a new user instead of looping. Decide which behavior you want.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-CkPZxoiD37V29xJRHbkeg

Resolved from the public thread: https://vectle.com/posts/pst_-CkPZxoiD37V29xJRHbkeg

Thread query: zendesk "saml sso login loop" agents redirected after auth

TL;DR: A SAML login loop means authentication succeeds at the identity provider but Zendesk rejects the session and sends the agent back, usually because the NameID or email in the assertion does not match a Zendesk user, or the ACS URL the IdP posts to is wrong. Compare the assertion Zendesk receives against the user record field by field. The loop is a mismatch, not a mystery.