OAuth Redirect Abuse: Detection and Defensive Controls

OAuth redirect abuse uses a legitimate authorization endpoint as the first hop to an attacker-controlled destination. The trusted identity-provider hostname does not make the final destination trustworthy. Defenders should inspect the complete redirect chain, govern application consent, and correlate email, identity, browser, and endpoint signals instead of classifying a link from its first domain alone.

Microsoft documented active campaigns in March 2026 that targeted government and public-sector organizations. The observed links used silent authorization requests and intentionally invalid scopes. When the request failed, the identity provider returned an OAuth error to the redirect URI registered for the attacker's application. The failed flow did not give the attacker an access token; the redirect enabled phishing, malware delivery, and limited session-state probing.

This is abuse of by-design behavior, not evidence that every OAuth redirect or prompt=none request is malicious.

What happens in the observed attack

The sequence Microsoft reported was:

1. An attacker registered an OAuth application under an account or tenant they controlled.
2. The application used an attacker-controlled redirect URI.
3. A phishing lure linked to a legitimate authorization endpoint with parameters intended to make silent authorization fail.
4. The authorization server sent the OAuth error response to the application's registered redirect URI.
5. The attacker-controlled page continued the social-engineering or malware-delivery chain.

Some campaigns placed an encoded target email in state, allowing the landing page to prefill an address. Microsoft also observed redirects to attacker-in-the-middle phishing frameworks and, in one campaign, ZIP archives containing shortcut and HTML-smuggling components.

The important boundary is that the authorization server did not accept an arbitrary redirect destination supplied without an application relationship. The attacker first controlled an OAuth application and its registered redirect URI. Exact redirect matching remains important, but it does not by itself stop a malicious developer from registering a destination they already control.

Why a trusted login hostname is not enough

The first visible host may be login.microsoftonline.com or another legitimate provider. That establishes where the authorization request begins, not where the browser will finish after success or failure.

Likewise, the following signals are not conclusive on their own:

• prompt=none is a defined way to request an authorization result without interactive UI. Legitimate applications use it, although Microsoft observed attackers using it to force a silent error path.
• A broad scope can be excessive, but a scope name is meaningful only in the context of the authorization server and application.
• A missing state can expose an OAuth client to request-forgery or response-injection risks, but inspecting a third party's link cannot prove how that client correlates requests.
• A state value may be opaque application state. Microsoft observed encoded email addresses in the campaigns, but encoding alone is not a reliable maliciousness test.

A static risk score built from these fields will produce both false positives and false negatives. It also cannot observe the redirect chain, application ownership, tenant consent, endpoint behavior, or later payload execution.

Detection for security teams

Treat the complete chain as the unit of investigation.

Email and browser telemetry

• Preserve and expand the original URL rather than allowlisting it because the first hop is a known identity provider.
• Look for authorization URLs with prompt=none plus deliberately invalid or unexpected scopes in unsolicited messages.
• Capture the redirect destination and subsequent hops. Escalate when an authorization error lands on an unknown domain, triggers a download, or leads to a credential-entry page.
• Correlate the click with message theme, sender history, attachment behavior, newly seen domains, and user reports. A single parameter is not a verdict.

Identity and application telemetry

• Review newly introduced enterprise applications, consent grants, service principals, publishers, owners, redirect URIs, and requested permissions.
• Alert on unusual consent activity and applications requesting privileges unrelated to their stated function.
• Investigate repeated failed silent-authorization requests when they align with suspicious email or browser activity.
• Remove or disable malicious applications and revoke associated grants according to the identity provider's incident-response procedures.

Endpoint telemetry

• Correlate an OAuth-link click with archive downloads, shortcut execution, script interpreters, DLL side-loading, or outbound connections from newly launched processes.
• Quarantine and investigate delivered files using established endpoint procedures. Do not execute a sample merely to confirm the redirect.

Microsoft publishes product-specific hunting queries and observed indicators in its campaign report. Indicators age quickly, so use them as investigation pivots rather than permanent proof of compromise.

Controls for tenant administrators

Tenant controls reduce exposure even though they cannot change how every external authorization server handles errors.

• Limit user consent to applications and permissions that meet the organization's policy. Route higher-risk consent through an administrator review process.
• Regularly review granted permissions and remove unused, abandoned, or overprivileged applications.
• Prefer verified publishers and explicitly approved applications where the platform supports those controls, while recognizing that publisher verification is not a guarantee of benign behavior.
• Apply Conditional Access and identity-risk controls based on the organization's threat model.
• Keep email, identity, browser, and endpoint detections connected. The campaign crossed those boundaries, so a single-domain blocklist is insufficient.
• Teach users to evaluate the final destination and the application or consent context. A familiar login hostname at the start of a link does not validate the landing page.

If a user entered credentials or opened a delivered file, follow the appropriate credential-compromise or endpoint-response playbook. Do not assume that changing a password alone invalidates every session or token.

Controls for OAuth client developers

These controls protect an application you operate. They do not turn its callback into a detector for unrelated malicious applications.

1. Register the minimum required redirect URIs and use exact matching. Avoid wildcard and open-redirect patterns.
2. Use an OAuth or OpenID Connect library that implements the provider's current guidance.
3. Bind the authorization response to the browser transaction using a one-time value. Depending on the protocol and library, that may be state, PKCE, an OpenID Connect nonce, or a combination.
4. Reject responses that cannot be correlated to a request your application initiated, including error responses.
5. Do not place email addresses, secrets, tokens, or unnecessary personal data in state. Treat authorization-response parameters as untrusted input and avoid logging sensitive values.
6. Request only the scopes needed for the current feature and explain why they are needed.
7. Validate tokens according to the provider and protocol requirements. A successful redirect is not proof that the user is authorized for an application resource.

Google's web-server OAuth documentation, for example, requires the redirect URI to match a configured URI and directs clients to generate and verify state to reduce request-forgery risk. Microsoft Entra likewise documents registered redirect URI restrictions and application-consent controls.

Controls for authorization-server operators

RFC 9700, section 4.11 describes authorization-server open-redirect risks. It requires exact string matching against registered redirect URIs, with the limited exception of localhost port handling for native applications, and recommends avoiding redirect URI patterns that can become open redirectors.

Authorization servers should also:

• reject authorization requests whose redirect_uri does not match the client registration;
• prevent client registration or redirect endpoints from introducing open redirects;
• make application identity and requested permissions clear before consent;
• detect and disable applications used for phishing or malware delivery; and
• avoid leaking unnecessary user or session information in error responses.

These are platform responsibilities. A relying organization cannot retrofit them by validating parameters only after a victim has already followed another application's redirect.

Safe investigation checklist

When an OAuth link is reported:

• preserve the original message and URL as evidence;
• use controlled security tooling to inspect the redirect chain without authenticating or opening downloaded content;
• identify the authorization host, client identifier, registered or resulting destination, and requested scopes;
• determine whether the application is known and approved in the affected tenant;
• correlate identity events with email, browser, DNS, proxy, and endpoint telemetry;
• block confirmed malicious infrastructure and applications using supported administrative controls;
• revoke grants, sessions, or credentials only when the evidence and provider guidance support that action; and
• document what was observed separately from what remains inferred.

Do not paste a live authorization URL containing user identifiers, tenant details, or transaction state into an unrelated public analyzer. Redact sensitive values before sharing evidence, and retain the original only in the authorized incident system.

Sources

• Microsoft Defender Security Research Team: OAuth redirection abuse enables phishing and malware delivery
• IETF RFC 9700: Best Current Practice for OAuth 2.0 Security
• Microsoft Entra: Configure how users consent to applications
• Microsoft identity platform: Redirect URI restrictions and limitations
• Google OAuth 2.0 for web server applications

Bottom line

OAuth redirect abuse turns a legitimate identity-provider endpoint into a trusted first hop. The observed Microsoft campaigns used failed silent authorization to reach attacker-controlled destinations without obtaining an access token. Effective defense therefore depends on redirect-chain visibility, application governance, consent controls, and cross-domain detection—not a parameter checklist or the reputation of the first hostname.