Understanding OAuth Security: How Authorization Flows Work and How They're Exploited
OAuth 2.0 powers modern authentication across the web, but its complexity creates security blind spots.
Every time you click "Sign in with Google" or authorize an app to access your Microsoft 365 account, you're using OAuth—the protocol that has become the backbone of modern authentication and authorization on the web. OAuth 2.0 enables seamless single sign-on experiences and allows applications to access your data without ever seeing your password. But this convenience comes with significant security implications that many organizations overlook.
In recent years, OAuth has become a prime target for sophisticated attackers. The December 2025 discovery of ConsentFix—a consent phishing kit targeting Microsoft 365 users—highlighted just how dangerous OAuth-based attacks can be. Unlike traditional credential theft, OAuth attacks bypass multi-factor authentication entirely. Once a victim grants permissions to a malicious application, attackers gain persistent access that survives password changes.
Understanding OAuth isn't just for developers—it's essential knowledge for anyone responsible for organizational security. In this guide, we'll demystify how OAuth works, explore the different flow types and when each is used, examine real-world attack techniques, and provide concrete defensive strategies. Whether you're an IT administrator hardening Microsoft 365, a security analyst investigating suspicious app grants, or a developer implementing OAuth in your applications, this knowledge is critical for defending against modern identity-based attacks.
What is OAuth and Why It Exists
OAuth stands for Open Authorization. It's an open standard protocol that allows users to grant third-party applications limited access to their resources without sharing their credentials. Think of OAuth as a valet key for your digital life—it gives an application access to specific functions without handing over your master password.
The Problem OAuth Solves
Before OAuth, if you wanted a third-party app to access your email, you had two terrible options: share your actual password with the app (security nightmare), or create application-specific passwords that were difficult to manage and revoke. Both approaches violated the principle of least privilege and created massive security risks.
OAuth introduced a better model: delegated authorization. Instead of sharing credentials, the user authenticates directly with the service provider (like Google or Microsoft), then explicitly grants specific permissions to the requesting application. The application receives tokens—temporary credentials—that provide limited, revocable access.
Key OAuth Concepts
Understanding OAuth requires familiarity with its core actors:
OAuth vs. OpenID Connect (OIDC)
A common point of confusion: OAuth 2.0 is strictly an authorization protocol—it deals with what you can access, not who you are. OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0 that adds authentication—verifying who you are. When you "Sign in with Google," you're using OIDC. When an app accesses your calendar after sign-in, it's using OAuth. In practice, most implementations use both together.
OAuth 2.0 Flow Types
OAuth 2.0 defines several "flows" (also called "grant types") for different use cases. Each flow has distinct security properties, and choosing the wrong one can introduce vulnerabilities. Understanding these flows is essential for both implementing OAuth securely and recognizing attack patterns.
Authorization Code Flow (Recommended)
This is the most secure and widely recommended flow for web applications with a backend server. Here's how it works:
Security benefit: Tokens are exchanged server-to-server, never exposed in browser URLs or history.
Authorization Code Flow with PKCE
PKCE (Proof Key for Code Exchange) is a security extension that protects against authorization code interception attacks. It's now recommended for ALL OAuth implementations, not just mobile apps. PKCE works by having the client generate a random code_verifier and its hashed code_challenge. The challenge is sent with the authorization request, and the verifier is sent when exchanging the code for tokens. Only the original client can complete the exchange.
Implicit Flow (Deprecated)
The Implicit flow was designed for browser-based apps without a backend. It returns tokens directly in the URL fragment after authorization. This flow is now considered insecure and deprecated. Tokens in URL fragments can leak through browser history, referrer headers, and are vulnerable to token injection attacks. Use Authorization Code with PKCE instead.
Device Code Flow
Designed for devices with limited input capabilities (smart TVs, IoT devices, CLI tools), this flow displays a code that users enter on a separate device with a browser:
Security concern: Device code phishing attacks exploit this flow by tricking users into authorizing attacker-controlled requests.
Client Credentials Flow
Used for machine-to-machine (M2M) authentication where no user is involved—backend services, daemons, and automated processes. The application authenticates using its own credentials (client ID and secret) rather than on behalf of a user. This flow grants application-level permissions, which are typically more powerful and require admin consent.
How OAuth Tokens Work
OAuth issues two types of tokens, each serving a distinct purpose. Understanding the difference is crucial for both security and troubleshooting.
Access Tokens
Access tokens are short-lived credentials (typically 1 hour) that grant access to protected resources. When an application calls an API, it includes the access token in the Authorization header:
Authorization: Bearer eyJ0eXAiOiJKV1QiLC...
Access tokens are often JWTs (JSON Web Tokens) containing claims about the user, granted scopes, expiration time, and issuer. The resource server validates these claims before granting access.
Key properties:
Refresh Tokens
Refresh tokens are long-lived credentials (days to months) used to obtain new access tokens without user interaction. When an access token expires, the application uses its refresh token to get a fresh access token silently.
Security implication: Refresh tokens are the crown jewels of OAuth. If an attacker steals a refresh token, they can generate new access tokens indefinitely until the refresh token is revoked. This is why consent phishing attacks are so dangerous—they grant attackers refresh tokens that persist even after password changes.
Key properties:
OAuth Security Risks and Attack Vectors
OAuth's flexibility creates multiple attack surfaces. Security teams must understand these risks to implement effective defenses.
Consent Phishing (Illicit Consent Grant)
The most prevalent OAuth attack today. Attackers register a malicious OAuth application (often with a legitimate-sounding name like "Microsoft Security Update" or "IT Support Portal"), then send phishing emails containing authorization links. When victims click and approve the permissions, they unknowingly grant attackers access to their email, files, contacts, and more.
Why it's devastating:
Token Theft and Replay
Attackers who compromise a device or intercept traffic can steal OAuth tokens. Access tokens can be replayed until they expire. Refresh tokens can be used to generate new access tokens indefinitely. Attack vectors include malware extracting tokens from browser storage or application databases, man-in-the-middle attacks on poorly configured apps, and memory scraping from compromised systems.
Device Code Phishing
Attackers abuse the device code flow by initiating an authorization request, then tricking victims into entering the code. The victim sees a legitimate Microsoft login page and may not realize they're authorizing an attacker's session. This technique has been used in nation-state attacks, including campaigns attributed to Russian threat actors.
Redirect URI Manipulation
If an OAuth application allows open redirects or doesn't strictly validate redirect URIs, attackers can intercept authorization codes. This is why authorization servers should enforce exact redirect URI matching and why developers must never use wildcard redirects.
Excessive Scope Requests
Malicious applications request far more permissions than needed—a simple note-taking app requesting Mail.ReadWrite and Mail.Send should raise red flags. Users habituated to clicking "Accept" often grant these permissions without scrutiny.
Real-World Attack Examples
ConsentFix: The Consent Phishing Kit (2025)
Discovered in December 2025, ConsentFix represents a significant evolution in OAuth-based attacks. Unlike previous consent phishing campaigns, ConsentFix is a fully packaged phishing kit that automates the entire attack chain—from generating malicious application registrations to harvesting tokens and exfiltrating data.
How ConsentFix works:
The kit's commoditization of consent phishing means less sophisticated attackers can now execute these attacks at scale, significantly increasing the threat landscape.
NOBELIUM Device Code Phishing (2022-2024)
The threat actor behind the SolarWinds attack (also known as Midnight Blizzard or APT29) has extensively used device code phishing in campaigns targeting government agencies, NGOs, and technology companies. Attackers send messages via Teams, email, or other channels with urgent requests to authenticate using a device code. Because the authentication happens on a legitimate Microsoft login page, victims often don't realize they're authorizing an attacker's session rather than their own device.
Storm-0324 Teams Phishing (2023)
Microsoft observed threat actors using compromised Microsoft 365 tenants to send OAuth consent phishing links via Teams messages. Because messages came from legitimate (compromised) accounts, they bypassed many security controls. This campaign demonstrated how OAuth attacks can be combined with account compromise for maximum effectiveness.
Defending Against OAuth Attacks
Effective OAuth defense requires a multi-layered approach combining technical controls, monitoring, and user education.
Control OAuth Application Consent
In Microsoft 365/Entra ID:
Monitor OAuth Activity
Enable and monitor these signals:
Apply Conditional Access
Conditional Access policies can limit OAuth token usage:
Educate Users
Train users to recognize consent phishing:
Best Practices for Organizations
Implement these practices to minimize OAuth-related risk across your organization:
Establish App Governance
Enforce Least Privilege
Prepare Incident Response
When consent phishing is suspected, act quickly:
Conclusion
OAuth has revolutionized how applications access user data, enabling the seamless integrations we rely on daily. But its complexity and the trust users place in authorization prompts have made it a prime target for sophisticated attacks. Consent phishing, device code abuse, and token theft represent serious threats that bypass traditional security controls like passwords and MFA.
The discovery of tools like ConsentFix demonstrates that these attacks are becoming commoditized and accessible to a broader range of threat actors. Organizations must treat OAuth security as a critical priority—implementing technical controls to restrict app consent, monitoring for suspicious authorization activity, and educating users about the risks of granting permissions.
Whether you're securing a Microsoft 365 environment, developing OAuth-enabled applications, or simply trying to protect your personal accounts, understanding how OAuth works—and how it can be exploited—is essential knowledge in today's threat landscape. Start by auditing your current OAuth app consents, implement the defensive measures outlined above, and stay vigilant for the evolving techniques attackers use to abuse this powerful protocol.
Related Reading
Deepen your security knowledge with our related guides on Social Engineering Attacks and Microsoft 365 Security Best Practices. For the latest on OAuth-based threats, check our News section for coverage of the ConsentFix phishing kit and other emerging attacks.
