ITInnovationStation

For years, companies treated multi-factor authentication as the line that separated ordinary phishing from serious compromise. If a user gave up a password, the second factor was supposed to stop the attacker. If a login came from a strange country, conditional access could challenge it. If a fake Microsoft page collected credentials, better training and phishing-resistant authentication could reduce the damage. That model still has value, but it no longer covers the full identity problem.

Modern OAuth phishing changes the center of the attack. The criminal does not always need the password. The victim may never type a password into a fake website. The user may land on a real Microsoft page, complete a real sign-in, pass a real MFA prompt, and still hand the attacker exactly what they need.

The prize is not the password anymore. The prize is the authorization.

That shift matters because many organizations still measure account security by asking narrow questions. Was the password stolen? Was MFA enabled? Did the user approve the push notification? Did the sign-in happen from a suspicious IP? Those questions are still useful, but they miss the deeper issue. OAuth attacks abuse trusted authentication flows, application permissions, delegated access, and session artifacts that can survive long after the user forgets what they clicked.

The result is a new kind of identity compromise. It looks cleaner than old phishing. It can avoid the obvious fake login page. It can blend into approved SaaS behavior. It can pass through the same systems defenders rely on. It can leave the attacker with access to mail, files, contacts, cloud applications, and other data without needing to log in like the user over and over again.

This is why the OAuth and MFA issue deserves serious attention. It is not just another phishing trick. It is a warning that identity security has moved beyond the login screen.

What OAuth Is Supposed to Do

OAuth exists because modern applications need a way to access resources without asking for a user’s password. A calendar app may need to read a user’s calendar. A mobile mail app may need permission to sync messages. A help desk platform may need to connect to Microsoft 365. A reporting tool may need to pull data from a cloud service. OAuth allows that access through permission grants and tokens instead of password sharing.

In normal use, this is a good design. The user or administrator approves a specific application. The application receives scoped access. That access is supposed to be limited by permissions, time, policy, and tenant controls. The password remains with the identity provider instead of being spread across every app.

The problem is that attackers noticed the same thing defenders already knew: OAuth access can be powerful. A malicious app with the right permissions can read a mailbox. A stolen refresh token can allow repeated access. A device authorization flow can let the user complete authentication for a session the attacker started. A consent grant can give an external application long-running delegated rights.

In other words, OAuth reduces password sharing, but it creates a new access plane. That plane must be governed, monitored, and restricted. If it is treated as background plumbing, attackers will use it as a side door.

The Old Phishing Model

Traditional phishing was easy to explain. An attacker created a fake login page, sent a lure, collected a username and password, then tried to use those credentials before the victim or security team noticed. MFA made that harder. If the attacker only had the password, they still had to beat the second factor.

That created new attacker behavior. Some moved to push fatigue. Some used adversary-in-the-middle proxy sites. Some stole session cookies. Some called users and walked them through approvals. Others moved toward flows where the user signs in to the real provider but authorizes the wrong thing.

The last category is where OAuth phishing becomes dangerous. The user is no longer simply fooled by a bad copy of a login page. The user is tricked into approving an attacker-controlled request inside a real authentication process.

That is why the old advice is incomplete. “Check the URL” helps when the attacker sends a fake domain. It does not solve a case where the URL is real but the session context is hostile. “Never share your password” helps when the attacker asks for a password. It does not help when the attacker asks the user to enter a code on a legitimate page. “Approve MFA only when you are logging in” helps against random push prompts. It does not fully protect a user who believes they are logging into a meeting, document, help desk portal, remote session, or business application.

The user’s trust decision has changed. They are no longer just deciding whether a page is fake. They are deciding whether the authorization request belongs to them.

Device Code Phishing

Device code phishing is one of the clearest examples of this problem.

The device code flow was designed for situations where one device cannot easily handle a full browser login. Think of a smart TV, printer, command-line tool, meeting room device, or similar system. The device displays a short code. The user goes to a verification page on another device, enters the code, signs in, and approves access. The device then receives authorization.

That is normal behavior when the user owns both sides of the process.

The attack starts when the criminal controls the device side. The attacker begins the authorization flow and receives a user code. Then they send that code to the victim using an email, chat message, QR code, fake meeting notice, document lure, or support pretext. The victim is told to visit the real verification page and enter the code. The victim signs in and completes MFA. The attacker’s session receives valid access.

From the user’s point of view, the page may look completely legitimate because it is legitimate. The MFA prompt may be normal because it is normal. The failure is not that the identity provider accepted a fake password. The failure is that the user approved a session they did not initiate.

That detail is easy to miss. The victim may say, “I never gave my password to anyone.” They may be telling the truth. They may say, “I only logged into Microsoft.” That may also be true. The compromise happened because the attacker caused the victim to complete the wrong login flow.

This is why device code phishing is so effective against trained users. It avoids many of the obvious signals they were taught to look for.

Consent Phishing

Consent phishing uses a different path but reaches a similar result.

Instead of tricking the user into entering a device code, the attacker presents an application permission request. The app may claim to be a document viewer, meeting scheduler, security scanner, invoice portal, PDF tool, voicemail platform, AI assistant, or productivity add-in. The user signs in and sees a consent screen. The screen asks for access to data such as mail, files, contacts, profile information, calendar data, or offline access.

If the tenant allows users to consent to apps, the user may approve the request without administrator review. Once approved, the malicious or over-permissioned application can act through the granted rights.

The danger is not always obvious to the user. A prompt that says an app wants to “read your profile” may sound harmless. A request for mail access may appear connected to a workflow. A request for offline access may look like technical noise. Many users have been trained by modern software to click through permission prompts because so many tools ask for access during routine onboarding.

That habit is exactly what attackers exploit.

Consent phishing is powerful because the attacker does not need to keep asking the user for help. Once the grant exists, the app may continue accessing data until the grant is removed, the app is blocked, or the session material is revoked. Password resets alone may not remove the application’s permission. MFA may not undo consent that was already granted.

This creates a quiet persistence problem. The user account might look clean from a password perspective while an application remains authorized behind the scenes.

Why MFA Does Not Fully Solve This

MFA is still valuable. It stops many attacks. It makes password theft less useful. It raises the cost for attackers. The problem is not that MFA is bad. The problem is that MFA was not designed to answer every question OAuth attacks create.

MFA usually answers this question: “Can the person completing this sign-in satisfy an extra proof requirement?”

OAuth phishing changes the question to: “Does the user understand what session or application they are authorizing?”

Those are different problems.

In a device code attack, the victim may complete MFA correctly. The identity provider sees a valid user and a completed challenge. The issue is that the approval is tied to the attacker’s device authorization request. The factor worked, but it worked for the wrong purpose.

In a consent attack, MFA may verify the user before the consent screen appears. Again, that proves the user is present. It does not prove the application is trustworthy, the permissions are appropriate, or the approval should be allowed.

This is the weak point in many security programs. They treat MFA as if it confirms intent. It does not. It confirms authentication strength. Intent still depends on context, policy, and user comprehension.

That is why organizations need controls around OAuth itself. They need to govern which flows are allowed, which users can consent, which applications can receive permissions, which scopes require admin review, and which token behaviors generate alerts.

The Token Problem

Tokens are attractive because they represent access after authentication. An access token can be used to call an API. A refresh token can be used to obtain new access tokens. A delegated grant can let an application act as the user for approved resources. These artifacts are useful for legitimate software, but dangerous when stolen or abused.

The attacker wants these artifacts because they can reduce the need for repeated interaction. Instead of logging in manually every time, the attacker can use APIs. Instead of triggering obvious browser sessions, they can query mail, files, or user data through service calls. Instead of asking for passwords, they can rely on the user’s one-time approval.

This creates a different kind of forensic trail. Analysts may not see a simple suspicious login followed by manual mailbox browsing. They may see API calls. They may see non-interactive sign-ins. They may see application activity. They may see file downloads from a trusted app. They may see a new enterprise application with delegated permissions. They may see mailbox access without the obvious signs of a normal user session.

That makes response harder if the team only reviews interactive sign-ins.

A mature investigation must ask several questions.

Which application received access?

Which user approved the grant?

Which scopes were granted?

Was device code flow used?

Were refresh tokens issued?

Was offline access present?

Which IPs used the token afterward?

Did the activity move from authentication into Graph API calls, mailbox reads, file downloads, or device registration?

Were inbox rules, forwarding settings, delegates, or hidden mailbox changes created?

Did the attacker access documents containing passwords, VPN details, finance data, contracts, or customer information?

Those questions shift the investigation away from “change the password and move on” toward “remove the trust object, revoke the access path, and inspect the data touched.”

Why This Is Hard for Users

The user experience around OAuth is not built for careful risk analysis. Consent prompts often contain technical permission names. Many people do not know the difference between reading basic profile information, reading all mail, sending mail, accessing files, or maintaining offline access. Even administrators can miss the long-term impact of a bad grant if the app name looks normal.

Device code prompts are even more confusing. A user may be told, “Enter this code to join the meeting,” “Enter this code to review the document,” “Enter this code to verify your account,” or “Enter this code so support can connect you.” The verification page may be real. The branding may be familiar. The MFA challenge may behave as expected.

A trained user might still think everything is safe because they did not see a strange domain.

The best user guidance must be simple.

Never enter a device login code unless you started the sign-in on a device you are physically using.

Never enter a code sent by email, chat, text, voice call, or ticket comment.

Never approve an app permission request unless you expected it, understand the data being requested, and know the application is approved by the company.

Treat “offline access,” “read mail,” “read files,” “send mail,” and “manage settings” as high-risk permissions.

Report unexpected Microsoft code prompts, app consent screens, and permission requests immediately.

This message is more useful than generic phishing advice because it names the exact behavior attackers need from the victim.

Why This Is Hard for Security Teams

Security teams have a different problem. OAuth abuse cuts across several administrative areas. Identity admins may own Conditional Access. Messaging teams may own mailbox auditing. Cloud app teams may own application consent. SOC analysts may own alerts. Help desk teams may handle user reports. SaaS owners may approve third-party integrations. No single group may have the full picture.

That split creates gaps.

One team may see the user authenticated successfully.

Another may see a new app consent event.

Another may see mailbox access.

Another may see OneDrive downloads.

Another may see the user report a strange code prompt.

If those signals are not connected, the incident can look like noise.

OAuth phishing demands identity-centered correlation. The organization needs a view that connects the user, app, consent grant, token use, device code flow, API activity, mailbox changes, file access, and downstream SaaS exposure.

Without that correlation, defenders may close the ticket after a password reset while the attacker still has a valid grant.

The Business Impact

The business impact depends on the user, permissions, and data exposure.

For an executive, the attacker may gain insight into strategy, legal discussions, acquisitions, sensitive negotiations, or board communications.

For finance staff, the attacker may search invoices, payment instructions, vendor contacts, ACH forms, bank details, wire approvals, or payroll files.

For IT admins, the attacker may find credentials, scripts, service account details, remote access notes, firewall information, break-glass procedures, or license portals.

For sales teams, the attacker may access customer lists, pricing, proposals, contracts, quotes, and pipeline data.

For HR, the exposure may include employee records, tax forms, medical notes, disciplinary matters, onboarding documents, or background-check material.

For legal teams, the attacker may read privileged discussions, discovery material, settlement terms, and confidential attachments.

That is why OAuth phishing should not be treated as a low-level account issue. One bad consent grant or device code session can turn into data theft, fraud, internal phishing, vendor compromise, or regulatory exposure.

The damage may not be obvious at first. The attacker may spend time searching, downloading, and staging future attacks. They may avoid loud actions like mass forwarding. They may use the victim’s account only to gather enough context for a more profitable second step.

How Attackers Make the Lure Work

The social-engineering side is often built around urgency and normal business activity. The lure does not need to be exotic. It only needs to make the requested action feel ordinary.

A meeting invite says the user must verify access before joining.

A document notice says the file is protected and requires code confirmation.

A voicemail alert says playback requires authentication.

A fake support message says the user must enter a code to complete a remote assistance session.

A vendor portal says the user must approve an app to view an invoice.

A shared file notification says a PDF viewer needs permission to open the file.

A QR code leads the user into the flow from a mobile device.

A Teams message from a compromised account gives the request internal credibility.

The attacker may pair the lure with business-specific language. If they know the user works in finance, they mention invoices. If they target IT, they mention ticket validation. If they target executives, they mention a board document. If they target HR, they mention a candidate package or payroll update.

The more normal the lure feels, the less likely the victim is to pause.

The Defensive Baseline

A strong defense starts by reducing exposure.

First, block device code flow where it is not needed. Many organizations have little legitimate use for it. Some have room systems, command-line tools, or specialty devices that require it. Those cases should be documented and restricted. The default should not be unrestricted availability for every user and every app.

Second, restrict user consent. Broad self-service consent is convenient, but risky. Users should not be allowed to approve high-impact application permissions without review. At minimum, consent should be limited to verified, low-risk applications with low-impact scopes. Stronger environments should require admin approval for most third-party access.

Third, enable an admin consent workflow. Business users still need software. The answer is not to break every workflow. The answer is to create a review path where users can request approval and reviewers can inspect the app, publisher, scopes, purpose, owner, and data risk before granting access.

Fourth, monitor OAuth applications. Security teams should inventory approved apps, delegated permissions, authorized users, high-risk scopes, rare apps, newly approved apps, and apps approved by privileged users. This should not be a one-time cleanup. It should be recurring governance.

Fifth, alert on device code usage. If device code flow is rare in the tenant, any use should be reviewed. If it is common, establish a baseline by user, app, device type, location, and timing. Look for unusual combinations.

Sixth, connect authentication events to post-authentication behavior. A device code sign-in followed by mailbox reads, file downloads, new inbox rules, or unusual API calls should receive higher priority than the sign-in event alone.

Seventh, build revocation into the response process. The team should know how to revoke sessions, remove grants, disable suspicious apps, delete unauthorized service principals, block re-consent, and validate that access stopped.

Eighth, train users on the specific action. General phishing training is not enough. Users must know that real Microsoft pages can still be part of a trick if the code or consent request was initiated by an attacker.

Controls That Matter Most

The highest-value controls are the ones that remove the user from risky approval decisions.

Blocking or limiting device code flow is powerful because it prevents a whole class of attacks from reaching the user.

Restricting consent is powerful because it stops random users from giving outside applications access to corporate data.

Admin consent workflow is useful because it turns a rushed user click into a controlled review.

OAuth app monitoring is necessary because today’s approved app can become tomorrow’s exposure.

Conditional Access can help when it requires compliant devices, trusted locations, stronger authentication methods, or app restrictions for sensitive resources.

Session revocation is necessary for cleanup, but it should not be the only plan. Revocation after compromise is response, not prevention.

User education helps, but it should support technical controls, not replace them.

A company that relies only on training is asking every employee to make protocol-level security decisions during a stressful workday. That is not realistic.

Incident Response

When an OAuth phishing incident is suspected, the response must move quickly and cover more than the password.

Start with the user and timeline. Identify when the suspicious prompt occurred, what the user clicked, what code was entered, what app was approved, and what MFA events happened. Preserve sign-in logs, audit events, app consent records, mailbox activity, and cloud app telemetry.

Next, determine the path. Was it device code flow? Was it app consent? Was it adversary-in-the-middle token theft? Was it a malicious third-party integration? The containment steps overlap, but the root access object may differ.

Then revoke active sessions and refresh material for the user. This reduces ongoing access, but the team should not assume it is instant or complete without validation.

Remove or disable suspicious application grants. If an enterprise app or service principal was created, review it. If the user granted delegated permissions, remove them. If admin consent was granted by mistake, treat that as a larger incident.

Inspect mailbox changes. Look for new inbox rules, forwarding, delegates, hidden rules, altered junk settings, suspicious transport behavior, and unusual send activity.

Review file access. Check OneDrive, SharePoint, Teams files, and downloaded attachments. Pay attention to finance, HR, legal, IT, and customer folders.

Search for exposed secrets. If the attacker accessed mail or files, assume they may have found passwords, keys, remote access instructions, VPN details, API tokens, backup credentials, or vendor portals.

Look for follow-on actions. Check device registrations, app registrations, group changes, role changes, new service principals, and internal phishing from the affected account.

Notify affected parties based on data exposure, not only account access. A quiet mailbox read may still create reporting obligations depending on what was accessed.

Finally, close the control gap. If device code flow was abused, restrict it. If user consent was abused, tighten it. If alerts were missing, build them. If response was slow, create a runbook.

A Practical Tenant Review Checklist

A practical review should answer these questions.

Can normal users approve third-party applications?

Can users approve apps with mail, file, contacts, calendar, or offline access?

Is admin consent workflow enabled?

Who reviews application consent requests?

Are reviewers checking publisher, scopes, tenant usage, and business owner?

Is device code flow allowed?

Which users and apps used device code flow in the last 30, 60, and 90 days?

Are there known business cases for that flow?

Are any privileged users using it?

Are any risky sign-ins tied to it?

Which OAuth apps have high-risk delegated permissions?

Which apps are rare or newly approved?

Which apps are approved by executives, finance staff, IT admins, or service accounts?

Are refresh tokens and sessions revoked during account compromise response?

Are app grants removed during cleanup?

Are mailbox rules checked?

Are OneDrive and SharePoint downloads reviewed?

Are app consent events sent to the SIEM?

Are non-interactive sign-ins reviewed?

Are Graph API patterns monitored?

Is there a user-facing warning about device login codes?

Are help desk staff trained not to ask users to enter codes they did not initiate?

If the answer to these questions is unknown, the tenant likely has blind spots.

The Bigger Lesson

OAuth phishing shows that identity risk has moved from simple credential theft into trust manipulation. Attackers are no longer limited to stealing passwords. They can trick users into authorizing sessions, approving applications, granting data access, and creating durable trust paths.

That means identity security must become broader. It must cover users, devices, applications, grants, tokens, sessions, APIs, SaaS connectors, and data access. It must treat third-party integrations as possible attack paths. It must monitor what happens after authentication, not only whether authentication succeeded.

This is also a reminder that security tools can create false comfort when the control is measured too narrowly. MFA enabled does not mean OAuth abuse is solved. Conditional Access deployed does not mean risky flows are blocked. A clean password reset does not mean malicious app access is gone. A user with no suspicious interactive login may still have exposed data through delegated API calls.

The attacker adapts to whatever defenders trust too much.

For several years, organizations trusted MFA as the final answer. Now attackers are proving that the authorization layer deserves the same scrutiny.

What Good Looks Like

A well-defended environment handles OAuth risk before the user sees the lure.

Device code flow is blocked unless a documented business need exists.

User consent is limited or disabled.

Admin consent requests are reviewed by people who understand data risk.

High-risk OAuth scopes trigger alerts.

New apps are reviewed.

Rare apps are investigated.

Privileged users cannot casually grant access to unknown tools.

Device code sign-ins are monitored.

Non-interactive token use is correlated with the original sign-in.

Mailbox and file activity are tied back to identity events.

Incident responders remove grants, revoke sessions, check data access, and validate containment.

Users know one clear rule: never enter a device login code unless they initiated the sign-in on a device they are using.

That is a much stronger position than relying on MFA alone.

Closing Thought

The modern identity attack is not always a stolen password. Sometimes it is a valid login attached to the wrong session. Sometimes it is a real user approving a dangerous app. Sometimes it is a trusted token used from an attacker’s infrastructure. Sometimes it is a third-party integration that quietly holds too much access.

That is the heart of the OAuth MFA issue. The attacker is not always trying to break authentication. They are trying to make authentication work for them.

The response is not to abandon MFA. The response is to stop treating MFA as the finish line. Authentication is only one step in the chain. Authorization, consent, token handling, application trust, and session behavior are just as important.

The organizations that understand this shift will close the gap before attackers turn it into routine access. The ones that keep thinking only in terms of passwords will keep finding out that the account was “protected” right up until the moment the user approved the attacker’s request.