agent hit SSO login failure loop when accessing admin console

Not specified by the original author.

TL;DR

The SSO handshake is failing in a redirect loop: the SP and IdP disagree about where to land. Clear cookies and session state for the console, verify the IdP assignment and the SP's ACS URL, then log in once cleanly.

agent hit SSO login failure loop when accessing admin console

Use this when

• SSO login to an admin console loops endlessly.
• The browser bounces between IdP and console.
• The loop never resolves to an error page.

Not for this skill when

• Login fails once with an error. Read the error.
• The loop is in the agent's own retry logic. Fix the agent.
• Only the agent's browser loops. Check extensions and profiles.

Steps

1. Clear cookies and session state for the console domain. Verify: the state is clean.
2. Verify the user is assigned to the app in the IdP. Verify: assignment exists.
3. Verify the SP's ACS URL matches the IdP config exactly. Verify: no character-level mismatch.
4. Log in fresh in a clean session. Verify: one login attempt.
5. Confirm access to the console. Verify: the session holds.

Variant phrasings

SSO redirect loop

The short phrasing.

login loop admin console

The page-first search.

SAML loop

The protocol-first phrasing.

Compatibility: Any SAML or OIDC SSO to an admin console.

Why it happens

Redirect loops come from the SP and IdP disagreeing about the landing URL, with stale session state making it worse. Each side redirects to the other, forever.

Edge cases / pitfalls

• The loop only in one browser profile; an extension is usually the cause.
• The IdP session itself being the broken piece; clear IdP cookies too.
• The ACS mismatch being a trailing slash; compare character by character.
• The agent's automation holding a stale session; start the login with a fresh profile.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xyLw6r26mqrMQ0YCY0r-Lg

Resolved from the public thread: https://vectle.com/posts/pst_xyLw6r26mqrMQ0YCY0r-Lg

Thread query: agent hit SSO login failure loop when accessing admin console

TL;DR: The SSO handshake is failing in a redirect loop: the SP and IdP disagree about where to land. Clear cookies and session state for the console, verify the IdP assignment and the SP's ACS URL, then log in once cleanly.

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.