Microsoft Entra ID 1-Click Open Redirection via OAuth Error Handling Abuse

Researchers associated with Tenable have discovered new techniques to trigger 1-click open redirection attacks in Microsoft Entra ID by abusing the OAuth error-handling mechanism.

The attack relies on an initial setup phase where a threat actor registers an OAuth application in an actor-controlled tenant and configures its redirect_uri to point to an attacker-controlled domain. When a victim clicks on a specifically crafted authorization link on the trusted login.microsoftonline.com domain, combinations of malformed parameters and application configurations trigger a server-side error condition.

Microsoft’s by-design error-handling processes this failure and issues an HTTP redirect that automatically forwards the error parameters directly to the attacker-controlled redirect_uri. Because this platform evaluates these errors post-authentication but pre-consent, a victim with an active Microsoft session is redirected instantly without any interstitial warning prompts, bypassing the OAuth consent screen and enabling phishing campaigns, credential theft, or malware delivery.

Note: Prior to disclosure, Microsoft published a blog describing OAuth redirection abuse techniques that exploit malformed parameters within the authorization URL to trigger error-based redirects. The techniques disclosed here differ in that the error conditions are triggered by the OAuth application’s server-side configuration in Entra ID, rather than by detectable anomalies in the link itself — making the authorization URL appear fully legitimate to the victim and to URL inspection tools.

Proof of Concept:

We have identified 3 different and new error scenarios that triggered the redirection:

• Error AADSTS700051
  • “AADSTS700051: response_type ‘token’ is not enabled for the application…”
• Error AADSTS700054
  • “ADSTS700054: response_type ‘id_token’ is not enabled for the application…”
• Error AADSTS9002331
  • “AADSTS9002331: Application {app_client_id} is configured for use by Microsoft Account users only. Please use the /consumers endpoint to serve this request…”

Setup:

• Register an OAuth application in an attacker-controlled Microsoft Entra ID tenant.
• Configure the application’s redirect_uri to point to an attacker-controlled domain (such as a phishing site or malware delivery host).
• Depending on the specific error scenario to be triggered, configure the application settings as follows:
  • For AADSTS700051: Configure the application as multi-tenant and disable implicit flow.
  • For AADSTS700054: Ensure the hybrid flow is disabled.
  • For AADSTS9002331: Configure the application to be used exclusively with personal Microsoft accounts.

Attacker:

• Craft a legitimate-looking Microsoft Entra ID authorization link targeting the /common endpoint, incorporating your application’s client_id. Use one of the following links based on the setup:
  • Scenario 1 (AADSTS700051):
    • Example link: https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id={app_client_id}&response_type=token&scope=User.Read
  • Scenario 2 (AADSTS700054):
    • Example link: https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id={app_client_id}&response_type=id_token&scope=User.Read
  • Scenario 3 (AADSTS9002331):
    • Example link: https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id={app_client_id}&response_type=code&scope=User.Read
• Distribute the crafted link to the targeted victim via a phishing email or message.

Victim:

• (Precondition) The victim must have an active Microsoft session or log in after clicking the link.
• Open the URL provided by the attacker.
• The victim is silently and instantly redirected to the attacker-controlled redirect_uri along with the error parameters, bypassing any consent screens or warning prompts.