How do I troubleshoot users getting redirected to the wrong identity provider?

When users are redirected to the wrong identity provider (IdP), it’s usually because of one of a few things: incorrect routing rules, cached sessions, stale cookies, or app/config mismatches. Here’s a practical way to troubleshoot it.

1) Confirm the expected routing logic

First, verify how the app decides which IdP to use:

• Domain-based routing (e.g., user@companyA.com → IdP A)
• Group/role-based routing
• App-specific policy
• Manual IdP selection
• Discovery/home realm behavior

Check whether the user’s account should route to a different IdP based on:

• email domain
• aliases
• group membership
• account source
• tenant/organization mapping

2) Reproduce with a clean browser session

A very common cause is existing SSO state.

Try:

• incognito/private window
• different browser
• clear cookies for the app and IdP domains
• sign out of all related IdPs first

If the issue disappears in a clean session, the problem is likely:

• stale session cookies
• cached login hints
• remembered account selection
• existing SSO session at the wrong IdP

3) Inspect the actual redirect flow

Use browser dev tools or a network trace and look at:

• initial URL
• redirects (302, 303)
• SAMLRequest / SAMLResponse
• redirect_uri
• login_hint
• domain_hint
• idp_hint
• acr_values
• tenant or realm

You want to see:

• which endpoint is sending the user away
• which IdP is being selected
• whether the wrong hint or parameter is being passed

4) Check for wrong or missing IdP hints

If your app or gateway sends hints to the IdP, confirm they are correct:

• login_hint points to the right user
• domain_hint matches the right tenant
• SAML idp/entityID selection is correct
• OIDC authorization request points to the intended issuer

A bad hint can override normal routing logic.

5) Verify configuration in the app and IdP

Look for mismatches in:

• ACS/redirect URI
• SAML entity IDs
• OIDC client IDs
• tenant IDs
• federation metadata
• IdP selection rules in your access proxy / IAM platform

Common mistakes:

• duplicated domains across IdPs
• wrong claim mapping
• stale federation metadata
• app pointing to the wrong environment (test vs prod)
• recently changed routing rules not fully propagated

6) Check user identity source and attributes

Sometimes the user is mapped incorrectly because their attributes are wrong.

Verify:

• username / UPN
• email address
• immutable ID / subject
• group membership
• account source
• directory sync status

If the user was moved between directories or tenants, the routing rules may still match the old identity.

7) Review recent changes

Ask whether anything changed recently:

• new IdP added
• domain verification changes
• claim mapping updates
• conditional access policy changes
• federation metadata refresh
• proxy/WAF changes
• SSO app reconfiguration

Redirect problems often start after a config change.

8) Check for duplicate or overlapping routing rules

If multiple rules match the same user, the platform may choose the first match or an unexpected default.

Look for:

• overlapping email domains
• wildcard rules
• fallback/default IdP settings
• conflicting assignments at app, group, and tenant levels

9) Inspect logs on the auth system

Check logs from:

• app
• IdP
• SSO gateway / broker / proxy
• directory sync service

Useful clues:

• which rule matched
• which IdP was selected
• whether the user was recognized as known or anonymous
• whether a session was reused
• whether an error caused fallback to a default IdP

10) Test with a known-good user and known-bad user

Compare:

• domain
• groups
• account type
• routing result
• cookies/session state
• IdP metadata and claims

This often reveals whether the problem is user-specific or rule-wide.

---

Common root causes

• stale browser session or cookies
• incorrect domain-to-IdP mapping
• wrong login hint/domain hint
• overlapping routing rules
• broken claim mapping
• user moved to a new IdP but old account still exists
• app configured against the wrong tenant/environment
• default fallback IdP taking over

---

Fast isolation checklist

If you want the quickest path:

1. Try private/incognito mode
2. Confirm the user’s email domain and groups
3. Check the redirect URL and hints
4. Review routing rules and default fallback
5. Inspect logs for which IdP was selected

If you tell me which stack you’re using — for example Azure AD / Entra ID, Okta, ADFS, Ping, Auth0, Keycloak, Duo, or a custom SAML/OIDC flow — I can give you a more specific troubleshooting checklist and the exact places to look.