Why do ADFS and SSO redirects make phishing harder to detect?

Why redirect-based phishing is harder to spot than a fake login page

Redirect abuse works because defenders and users are trained to treat sign-in hops as routine. The danger is not the redirect itself, it is the fact that the browser chain can begin on a legitimate trust anchor, then hand control to a hostile destination before the user has enough context to notice anything unusual.

A useful OpenID Connect Core 1.0 reference point is that modern SSO often relies on standard federation flows, which means the visible journey may include several authentic-looking transitions before the actual credential capture or consent abuse occurs.

That is why simple URL inspection is weak here. The page can still show an approved identity provider at the start, a familiar tenant in the middle, and only at the end reveal a malicious domain, so the visual cues that normally help people spot phishing arrive too late to be useful.

Why approved sign-in paths create believable abuse opportunities

SSO and ADFS centralize trust, so attackers prefer them because a single convincing redirect can inherit the credibility of the whole sign-in process. When the flow is familiar, users tend to focus on the login prompt rather than the domain sequence, and many security tools treat the redirect chain as normal unless they know which tenants, endpoints, and callbacks should exist.

The strongest defensive control is baseline knowledge of the expected identity surface. The Identity Provider and SSO Security Guide is directly relevant because it focuses on federation trust, session and token security, and monitoring the paths that attackers abuse when they steer legitimate sign-in flows off course.

The other issue is user expectation. Employees are conditioned to accept redirects during federated login, so an attacker does not need to create a perfect clone of the login page, only a plausible continuation of a workflow that people already assume is normal.

What defenders should look for in redirect-driven phishing

Detection gets harder when the abnormality is distributed across several steps instead of appearing in one obvious URL. The right questions are whether the domain chain is expected, whether the tenant is approved, whether the callback is known, and whether the sign-in sequence matches the organisation's normal federation pattern.

For this reason, Workforce Identity Security Guide is a strong companion resource: it covers federated SSO, phishing-resistant MFA, and the operational controls that reduce the chance that a legitimate-looking sign-in flow becomes an attacker-controlled handoff.

Defenders should also remember that redirect abuse often pairs with token or consent theft rather than password capture alone. Once the user has been steered through a trusted login experience, the attacker may be after the session, the token, or the authorization grant, which is why log review and browser telemetry matter as much as email filtering.

Risk and Threat Considerations

Redirect-based phishing is risky because it exploits trust in the authentication journey itself, not just trust in a page design. The abuse is especially effective when sign-in spans multiple domains, because each hop can look legitimate in isolation even when the full chain is malicious.

Failure mechanism: An attacker inserts or manipulates a step in a valid authentication or federation flow so the user reaches a malicious domain, consent screen, or token-harvesting endpoint while still believing the process is normal.

Impact: The result can be credential theft, token theft, session hijacking, or unauthorized access that is harder to distinguish from routine sign-in activity, which slows detection and complicates incident response.

Practitioner Guidance

What to verify: Baseline the approved identity provider domains, federation tenants, and redirect destinations, then alert on anything outside that allowlist. The practical test is whether your SOC can explain every expected hop in the sign-in path without guessing.

What good looks like: Security teams can correlate browser, IdP, and proxy logs to reconstruct the whole login path, not just the final landing page. That makes it possible to distinguish a normal federation hop from a malicious detour.

Common mistake: Treating “the login page looked real” as evidence of safety. In redirect phishing, the page can be real enough to pass a casual check while the critical abuse happens in the transition between trusted services.

Practitioner takeaway: The key defense is not recognizing every fake page, it is knowing which sign-in routes are supposed to exist and flagging any redirect chain that leaves that expected boundary.

Related resources from NHI Mgmt Group

• Why do trusted cloud redirects make phishing harder to block?
• Why do legitimate tools like form services make phishing harder to detect?
• Why do legitimate Google and Microsoft redirects make phishing harder to stop?
• Why do compromised Microsoft 365 mailboxes and nested attachments make phishing harder to detect in cloud email environments?