🔒 OAuth Security Risks 2026: The Hidden Danger of "Sign In with Google"
On this page
Stolen OAuth tokens now outsell raw username-and-password pairs on dark web markets by a factor of 12, according to Flare Systems' 2024 threat intelligence report. A stolen token does not expire when you reset your password. That asymmetry is exactly what attackers exploit.
OAuth security risks refer to the vulnerabilities in the Open Authorization protocol that let attackers gain persistent access to your accounts without ever touching your password. The "Sign in with Google" button is convenient, but each app you authorize with it creates a token that can outlive your next password change by weeks or months.
What Is OAuth?
OAuth (Open Authorization) is a protocol that allows a third-party application to access resources on a service on your behalf, without the app ever receiving your password. Instead of sharing credentials, the originating service issues a time-limited access token that grants the requesting app specific, scoped permissions.
For example, a task management app might request permission to read your Google Calendar. OAuth handles that handoff. The app gets a token granting read access to your calendar. It never sees your Google password, and technically it cannot write to your calendar unless you grant that additional scope.
The protocol was designed to solve a real problem: apps used to ask for your full login credentials to access your data on another service. That was catastrophically insecure. OAuth replaced it with a delegated permission model that is, in theory, much safer.
How OAuth Works
The standard OAuth 2.0 flow has four steps:
- Authorization request: The third-party app redirects you to the provider (Google, Microsoft, GitHub) with a list of requested permission scopes.
- User consent: You review the scopes and click "Allow" or "Deny." The permission dialog is the only moment you have full visibility.
- Authorization code: The provider sends a short-lived authorization code back to the app via a redirect URL.
- Token exchange: The app exchanges that code for an access token (short-lived, typically 1 hour) and a refresh token (long-lived, can last months or indefinitely).
That refresh token is the critical asset. It lets the app silently request new access tokens without prompting you again. Once an attacker has a refresh token, they can maintain access long after you believe you have secured your account.
The Real Risks: Token Theft and Consent Phishing
The danger is not in the protocol design itself. It is in how tokens are stored, how broad permission scopes are set, and how many people click "Allow" without reading what they are granting.
Three conditions combine to create OAuth risk:
- Overly broad scopes: Many apps request full account access when they only need a narrow permission. A photo editing app asking for access to all your Google Drive files is a red flag.
- Refresh token persistence: Access tokens expire quickly, but refresh tokens often do not. Steal the refresh token and you have durable access.
- No revocation on password change: Changing your password cancels your login sessions, but most providers do not automatically revoke OAuth tokens issued to connected apps. Microsoft's documentation confirms this behavior for Azure AD application tokens.
A 2024 analysis by Recorded Future found that infostealer malware families, including Lumma Stealer and Rhadamanthys, had added specific modules to harvest OAuth tokens from browser storage alongside traditional credential theft. Token harvesting has become a first-class objective.
Four OAuth Attack Types in 2026
1. Consent Phishing
The attacker creates a malicious application registered with a legitimate OAuth provider. They send a phishing link that looks like a normal login prompt. You never enter a password. You just authorize the attacker's app. Microsoft Threat Intelligence documented a 300% increase in consent phishing campaigns targeting Microsoft 365 tenants between 2022 and 2024.
2. Token Theft via Malware
Infostealer malware scans browser profiles for stored OAuth tokens, session cookies, and refresh tokens. Lumma Stealer, which Microsoft disrupted in June 2025, had infected over 394,000 Windows systems globally and was specifically designed to extract authentication tokens alongside passwords. Token theft is now often more valuable than the password itself.
3. Open Redirect Abuse
OAuth's authorization flow relies on a registered redirect URL to send the authorization code back to the legitimate app. If a legitimate application has an open redirect vulnerability, an attacker can manipulate the redirect to send the authorization code to their own server instead. OWASP specifically flags this in its API Security Top 10 guidance under "Security Misconfiguration."
4. Overprivileged Third-Party Apps
This is not an active attack but a passive risk. Every app you authorize with broad scopes becomes a potential entry point if that app is breached. The 2023 CircleCI security incident exposed customer OAuth tokens stored in their CI/CD pipeline. Anyone who had authorized CircleCI to access their GitHub repositories needed to immediately revoke access and rotate credentials.
Real-World OAuth Attacks
| Incident | Year | OAuth attack vector | Affected accounts |
|---|---|---|---|
| CircleCI breach | 2023 | Stolen OAuth tokens from CI/CD environment | Tens of thousands of GitHub-connected repos |
| Microsoft consent phishing campaign | 2024 | Malicious OAuth apps targeting Microsoft 365 | 300% increase in attempts; counts not disclosed |
| Cloudflare Okta incident | 2023 | Session token from Okta support system | 130 Okta customers |
| GitHub OAuth token leak (Heroku/Travis CI) | 2022 | Stolen OAuth tokens from integration service | Hundreds of organizations' private repositories |
"Attackers have largely shifted from stealing passwords to stealing authentication artifacts like tokens and cookies, which offer the same access with far less detection risk," according to Microsoft's 2024 Digital Defense Report.
How to Audit and Protect Your Connected Apps
Step 1: Audit your connected apps now
Most users have dozens of forgotten OAuth authorizations. Check each major platform:
- Google:
myaccount.google.com/permissions - Microsoft:
mysignins.microsoft.com/security-info/connected-accounts - Apple: Settings > [your name] > Password & Security > Apps Using Apple ID
- GitHub: Settings > Applications > Authorized OAuth Apps
- Twitter/X: Settings > Security and Account Access > Connected Apps
Revoke anything you do not recognize or no longer use. There is no downside to over-revoking. You can always re-authorize a legitimate app.
Step 2: Evaluate scope before clicking Allow
Before authorizing any new app, check the permission list carefully. A read-only note-taking app should not need access to send emails on your behalf. Excessive scope requests are a warning sign. NIST SP 800-63B guidance emphasizes least-privilege access as a core authentication principle: request and grant only the permissions required for the stated function.
Step 3: Use a dedicated password manager for site-specific accounts
One reason people rely heavily on "Sign in with Google" is convenience: they do not want to remember another password. A password manager like NordPass generates and stores strong, unique passwords for each site, removing the password-memorization problem without creating OAuth token risk. Site-specific accounts compartmentalize your exposure: if one site is breached, the attacker gets credentials only for that site, not a persistent token that touches your entire Google account.
Step 4: Monitor for suspicious app authorizations
Google and Microsoft both send email notifications when new apps are authorized. Do not dismiss these emails without reading them. If you receive an authorization confirmation you did not initiate, revoke the app immediately and check your account activity log for other suspicious access.
Step 5: Enable admin policies for organizational accounts
For organizations using Google Workspace or Microsoft 365, administrators should configure allow-lists restricting which OAuth applications employees can authorize. CISA's Secure Cloud Business Applications (SCuBA) guidance for Microsoft 365 specifically recommends restricting OAuth consent to administrator-approved apps only. Individual employees should not be able to authorize arbitrary third-party apps with access to corporate email and files.
Frequently Asked Questions
What is OAuth and how does it work?
OAuth (Open Authorization) is a standard protocol that lets a third-party application access your data on another service without seeing your password. Instead of sharing credentials, the service issues a short-lived access token that grants the app specific permissions. For example, a calendar app can read your Google Calendar events without ever receiving your Google password.
Does changing my password revoke OAuth tokens?
Not always. A password reset revokes your active login sessions, but OAuth access tokens and refresh tokens issued to third-party apps often remain valid until they expire or are explicitly revoked. This means an attacker who steals an OAuth token can retain access to your account even after you change your password.
What is an OAuth phishing attack?
An OAuth phishing attack presents a convincing authorization dialog asking you to grant a malicious app access to your account. Unlike password phishing, you never enter your credentials; you simply click "Allow." The attacker's app receives a valid OAuth token with whatever permissions you granted. Microsoft's threat intelligence team documented a surge in this technique in 2024, naming it "consent phishing."
How do I revoke access to connected apps?
For Google: visit myaccount.google.com/permissions. For Microsoft: visit mysignins.microsoft.com/security-info/connected-accounts. For Apple: go to Settings > [your name] > Password & Security > Apps Using Apple ID. For GitHub: go to Settings > Applications > Authorized OAuth Apps. Revoke any app you do not recognize or no longer use.
Is "Sign in with Google" safe to use?
Sign in with Google is generally safer than reusing a password across sites, because it does not expose your actual credentials. The risks come from granting excessive permissions, not auditing connected apps regularly, and falling for OAuth phishing. Used on legitimate services with minimal scopes granted, it is a reasonable authentication choice. For high-security accounts, site-specific passwords stored in a password manager provide cleaner access compartmentalization.
