Multifactor authentication (MFA) is often hailed as the gold standard for identity security.
In a world of rampant credential theft and phishing, MFA is a critical layer of defense that stands between an attacker and your kingdom. But what if there was a back door — a legacy loophole intentionally built into modern identity protocols that allows an attacker with only a username and password to walk right past your MFA guards?
This isn’t hypothetical. It’s a real-world threat enabled by a specific OAuth 2.0 grant type: the Resource Owner Password Credentials (ROPC) flow. For attackers who have phished or purchased stolen credentials, ROPC can be a golden ticket, turning a well-defended environment into an open book.
In this blog, we’ll dissect the ROPC flow, explain the role of public client applications and default first-party apps, provide a technical breakdown of how attackers exploit ROPC to bypass MFA, and leave you with practical detection and mitigation guidance.
The ghost of authentication past: what is ROPC?
The Resource Owner Password Credentials (ROPC) grant is one of the original authentication flows defined in the OAuth 2.0 framework. It was specifically designed to help legacy applications that are built to handle usernames and passwords directly to migrate to modern, token-based authentication. Think of command-line tools or old desktop clients that have no mechanism to render a web-based login prompt.
In the ROPC flow, the client application (the "public client") collects the user's username and password and then sends them to the authorization server's token endpoint directly. If the credentials are valid, the server issues an access token.This process is a direct violation of modern security principles.
The point of OAuth is to prevent applications from ever handling a user's password. ROPC is a deliberate, documented exception to that rule, and its continued existence is a source of significant risk. Microsoft is strongly against ROPC’s use, as it's fundamentally incompatible with MFA and other interactive sign-in flows.
To understand the attack, we first need to understand the tools. The bypass leverages two key concepts in cloud identity environments like Microsoft Entra ID (formerly Azure AD): public clients and default applications.
What is a public client?
In OAuth 2.0, client applications are categorized as confidential or public.
- Confidential clients: These are applications that can be trusted to store a secret, like a web application with a secure backend server.
- Public clients: These applications cannot be trusted to keep a secret. This category includes mobile apps, desktop applications, or single-page web apps (SPAs) where the source code is accessible. They are identified by a client_id (Application ID), which is public information.
An attacker doesn't need to register a new malicious application; they can simply masquerade as one of these trusted, pre-existing public clients using its well-known public client_id.
Default applications: the Trojan horses
When an organization sets up a cloud environment like Microsoft 356, the provider (Microsoft) automatically populates the identity tenant with dozens of pre-approved, first-party applications. These are the familiar tools your organization uses every day — Teams, Outlook, Azure CLI, SharePoint Online, and more.
For backward compatibility, many of these default applications are configured as public clients and, crucially, have the ROPC flow enabled. They are trusted by default within your tenant. An attacker doesn't need to find a vulnerability; they simply need to use a trusted, built-in feature in an unintended way. They leverage the implicit trust your organization places in these essential Microsoft applications.
The modern security model that ROPC bypasses
Before we dissect the attack, it's critical to understand the sophisticated security model that ROPC completely sidesteps. Modern identity platforms like Microsoft Entra ID operate on a Zero Trust principle, using a Conditional Access engine that evaluates multiple real-time signals before granting access. It’s not just about a password; it’s about context.
The diagram above shows how the attack is supposed to work. The system analyzes signals — user, location, device health, application — and then makes an intelligent decision: Allow, Block, or the crucial middle step, Require MFA. The ROPC flow shatters this model by being non-interactive; it has no way to support the "Require MFA" challenge, effectively blinding the Conditional Access engine.
From password to session token
With the stage set, let's go through the attack itself. It’s not a complex exploit, but a methodical abuse of a legitimate protocol, turning a single stolen password into a full-blown session that completely bypasses MFA.
The process begins after an attacker has obtained a valid username and password. Instead of using a browser, which would trigger the interactive MFA flow, they go directly to the source: the Microsoft identity platform's token endpoint. Using a tool like Postman or a simple script, they craft a direct HTTP POST request.
The request targets an endpoint such as
https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token and the body of this request is where the entire bypass is executed:
Let's dissect the attacker's payload:
- grant_type=password: This is the explicit instruction to the server: "Ignore interactive flows; I am giving you the user's password directly. This is an ROPC request."
- client_id: Here, the attacker impersonates a trusted, pre-existing Microsoft application, like the Azure CLI (04b07795...).
- username & password: The stolen credentials.
- scope: This is the attacker's masterstroke, defining the blast radius of the breach. It’s not just a technical parameter; it’s a wish list of permissions. A scope like offline_access is the most dangerous, as it grants a refresh_token for long-term persistent access. Adding a scope like https://graph.microsoft.com/.default requests all pre-approved permissions for the app, which can include reading emails, accessing files, and modifying user data.
Because the Conditional Access engine is blind to this non-interactive flow, it sees a valid password from a "trusted" app and has no mechanism to challenge for MFA. Assuming no policy explicitly blocks this legacy grant, the server has no choice but to issue the tokens.
The attacker receives their prize in the form of a JSON response:
With the access_token, the attacker gains immediate, authenticated access to the organization's data via APIs. With the refresh_token (granted by the offline_access scope), they can silently mint new access tokens for weeks or months, ensuring their foothold in the network remains long after the initial breach.
A single password has now officially defeated MFA.
How to detect and respond to RCOP abuse
ROPC abuse and MFA sweeps leave observable signals. Identity providers log authentication/token events: which grant type was used, which client_id requested tokens, whether a refresh token was issued, timestamps, and IP/contextual metadata. Aggregating and analyzing those logs is the cornerstone of detection.
High-level detection and response points include:
- Log collection: token endpoint and authentication events show grant_type=password or non-interactive token issuance. Those events are recorded in the cloud provider’s identity logs.
- Correlation: when identity logs are combined with user and data-access telemetry, anomalous patterns become visible — for example, non-interactive token grants for users who normally sign in interactively, unexpected refresh_token issuance, or API calls from client IDs not used by the organization.
- Alerting and response: flagged anomalous token activity should trigger investigation, token revocation, and targeted remediation (revoke refresh tokens, disable legacy flows for implicated apps, reset credentials, require reauthentication with MFA).
- Customer assurance: detection can be implemented without exposing internal detection mechanics — use the identity provider logs and standard signals to confidently triage suspicious token activity.
If detection highlights ROPC usage or anomalous refresh token grants, the immediate actions are straightforward: revoke suspicious refresh tokens, rotate the user’s credentials, and block or disable the legacy grant on the implicated app(s) while your infra team validates the change.
Explore more from Varonis Threat Labs.
Conclusion — legacy flows, modern risk
ROPC exists for legacy compatibility, but legacy compatibility is no excuse to accept systemic risk. The presence of public client IDs and first-party apps with permissive legacy grants creates a powerful avenue for attackers: a stolen password can be turned into persistent API access that bypasses interactive MFA.
Defense starts with reducing the attack surface: eliminate or tightly control legacy grants, limit refresh tokens for public clients, enforce phishing-resistant MFA, and monitor token activity. When detection flags suspicious ROPC usage, act fast — revoke tokens, rotate credentials, and close the legacy path.
