community SSO login loop redirects member between forum and product app

Not specified by the original author.

TL;DR

Fix this in community SSO by acting on the exact problem first: test the login in a private window to rule out stale cookies, then compare the return address configured in the forum with the one the product app sends, fixing any mismatch in scheme, trailing path, or domain, because a loop almost always means each side sends the member back to the other as if unauthenticated. Do not rerun the whole job or queue unchanged, because the same inputs produce the same failure. Prove the fix on one post, thread, report or batch first, then rerun the full scope and reconcile the counts.

SSO login loop redirects member between forum and product app

Use this when

• The operation in community SSO fails with this exact message or symptom: SSO login loop redirects member between forum and product app.
• The same failure repeats on retry with unchanged inputs.
• Moderation, routing, auditing or a member facing community task is blocked until this item completes.

Not for this skill when

• The message is an outage notice from the platform. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with a moderation judgment or content quality. That is a policy review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in community SSO, and copy the full message plus the post, thread, report or member involved into the run notes. Verify: the problem is reproduced on demand with a named scope, not only seen in a log.
2. Apply the specific fix for this problem: test the login in a private window to rule out stale cookies, then compare the return address configured in the forum with the one the product app sends, fixing any mismatch in scheme, trailing path, or domain, because a loop almost always means each side sends the member back to the other as if unauthenticated. Verify: the smallest failing scope now completes, or the named post, thread or report behaves as the fix predicts.
3. Check the neighbouring posts, threads, reports or members that share the same setting, rule or workflow, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in community SSO on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts or status against the source in community SSO so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Why it happens

Each side redirects when it cannot see a valid session, so a mismatched return address, a blocked third party cookie, or a session written on a different domain makes the two systems hand the member back and forth forever.

Variant phrasings

SSO login loop redirects member between forum and product app

The verbatim form searchers paste from the console, queue or report. Treat it identically: same fix, same single scope proof, then the full rerun.

How to fix - community SSO login loop redirects member between forum and product app

The how to phrasing for the same failure in community SSO. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

community SSO troubleshooting for this failure

The symptom first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Edge cases

• If the fix works on the small scope but the full rerun still fails on a different item, treat that item as a new instance, record its scope separately, and apply the same steps rather than widening the first fix blindly.
• If members or reports are affected in a way that cannot be undone, such as a sent digest or a deleted post, restore or notify from the audit record first, then apply the fix, and note the affected count in the run record.
• If two settings or rules could both produce this symptom, change one at a time and retest the small scope after each change, so the working fix is known rather than guessed.

Compatibility: community SSO at current versions, plus the admin console, moderation queue or API the query names; no extra tooling beyond the source system access needed to verify counts.

Provenance

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

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

Thread query: community SSO login loop redirects member between forum and product app

TL;DR: Fix this in community SSO by acting on the exact problem first: test the login in a private window to rule out stale cookies, then compare the return address configured in the forum with the one the product app sends, fixing any mismatch in scheme, trailing path, or domain, because a loop almost always means each side sends the member back to the other as if unauthenticated. Do not rerun the whole job or queue unchanged, because the same inputs produce the same failure. Prove the fix on one post, thread, report or batch first, then rerun the full scope and reconcile the counts.

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.