7 min read<\/p>\n
Multi-factor authentication locks the login. But it doesn\u2019t protect the key issued after sign-in. That\u2019s exactly where attackers strike now: they steal OAuth tokens that already contain a passed MFA and use them to access SaaS services without ever triggering a second factor. OAuth phishing has surged nearly thirty-nine-fold in the past year. More than one thousand SaaS environments were compromised.<\/strong><\/p>\n Key Takeaways<\/p>\n Related:<\/span>Edge devices as ransomware entry points<\/a> \/<\/span> When the security product itself is the vulnerability<\/a><\/p>\n What is an OAuth token?<\/strong> An OAuth token is a digital access credential issued by a service after successful login. Instead of re-entering password and second factor for every request, the app presents this token. It vouches: this access has already been authenticated. That convenience is the vulnerability.<\/p>\n The logic is brutally simple. MFA works at the moment of login. After that, the service issues a session or OAuth token that represents the authenticated state. Whoever gets hold of that token no longer needs to log in. They present the key that MFA already approved. The second factor isn\u2019t cracked; it\u2019s bypassed because, at the moment of attack, it\u2019s already in the past.<\/p>\n Device-code abuse is especially insidious. Designed for devices without keyboards, like smart TVs, it tricks victims into confirming a code that actually grants the attacker\u2019s device access. The victim completes a real, legitimate MFA-and unwittingly approves the rogue session. From the service\u2019s perspective, everything is correct: a legitimate user consented.<\/p>\n The uncomfortable truth: MFA was designed to solve a different problem. It prevents a stolen password from being enough on its own. Against a stolen token after successful login, it\u2019s useless because it\u2019s no longer in play at that point. Treating MFA as the final safeguard is like locking the front door while leaving the window wide open-the attacker walks right through the session.<\/p>\n Defense must shift from login to session. Checking access once isn\u2019t enough. The session itself needs monitoring and limits. A token that never expires and works from anywhere is a master key. One that expires quickly, ties to a device and location, and gets revoked on anomalies is far less valuable if stolen.<\/p>\n What makes a token valuable<\/p>\n What devalues it<\/p>\n The first lever is token lifespan. Many SaaS services default to generous settings because users rarely want to log in again. That convenience needs scrutiny. Shorter validity and forced re-authentication for sensitive actions shrink the window a stolen token can be used.<\/p>\n The second lever is Conditional Access. A token shouldn\u2019t work everywhere. If the same session suddenly appears from another country or an unknown device, it should be challenged-not silently accepted. Context checks like this are the real answer to stolen tokens because they protect usage, not just login.<\/p>\n \n MFA locks the door. If the attacker copies the key that follows, the best lock is useless. Sessions must be defended, not just logins.\n<\/p><\/blockquote>\n The third lever involves the Device-Code flow itself. Where it\u2019s unnecessary, restrict or disable it. And staff should treat every code prompt with the same suspicion as a password request on a random site. Confirming a code can authorize a foreign session. That one insight stops most Device-Code attacks.<\/p>\n None of these three levers removes MFA. It remains the foundation. But it\u2019s the first line, not the last. Ignoring the session after login abandons the very point where today\u2019s attacks strike. The good news: token lifespan, Conditional Access, and Device-Code hygiene are all configurable today-not inventions yet to come.<\/p>\n No, it\u2019s bypassed. The token is created after successful MFA and carries that authenticated state. Whoever steals it doesn\u2019t need to log in again, so no new factor prompt appears.<\/p>\n The Device-Code flow lets keyboard-less devices sign in. Attackers trick victims into approving a code that actually grants the attacker\u2019s device access. The victim completes real MFA and unwittingly approves a foreign session.<\/p>\n MFA works at the moment of login. The attack happens afterwards, during the already-established session. At that point MFA is no longer involved, which is why it can\u2019t stop a stolen token.<\/p>\n Check and shorten token lifetime, then activate Conditional Access. Both shrink the window of opportunity and the scope of a stolen token without replacing MFA.<\/p>\n Where it isn\u2019t needed, yes. Where it is, restrict and monitor it. Also educate staff that a code they\u2019re asked to confirm can authorise an unknown session.<\/p>\n\n
How a token bypasses MFA<\/h2>\n
Why Classic MFA Fails Here<\/h2>\n
\n
\n
What a SOC Should Actually Do<\/h2>\n
Frequently Asked Questions<\/h2>\n
If an OAuth token is stolen, does MFA get cracked?<\/h3>\n
What is Device-Code abuse?<\/h3>\n
Why isn\u2019t MFA enough against these attacks?<\/h3>\n
What\u2019s the fastest fix?<\/h3>\n
Should we disable the Device Code flow?<\/h3>\n