The nOAuth “flaw” is a symptom of industry anti-patterns

If you haven’t followed the news recently, Descope released an article diving into how their security researchers were able to abuse OpenID Connect (OIDC) ID token claims to spoof the user they are authenticating as for multi-tenant SaaS applications. You can read their research article here, nOAuth: How Microsoft OAuth Misconfiguration Can Lead to Full Account Takeover (

In conjunction with this, Microsoft has updated developer guidance for OpenID Connect and SAML assertions, and provided a blog post covering all of this, which can be found here, The False Identifier Anti-pattern (

Mulit-tenant SaaS applications are those applications, such as Canva or Sessionize, which allow you to authenticate with your Microsoft or Office 365 account. Without getting off track, this is what allows SaaS application vendors to develop applications that can integrate with an organizations Azure Active Directory environment requiring no effort on the part of administrators.

The Sessionize authentication screen allowing a user to select their identity provider.

And as it goes whenever there is a security problem, someone must fall on the sword. In this case Microsoft is taking the hit; unfortunately most new articles are incorrectly reporting on this as an Azure AD “flaw” that Microsoft had to “fix”. Kudos to Kurt Mackie (@kurmac) at Redmond Mag for being the only article to accurately report on this problem, which you can find here, Microsoft Advises App Developers About ‘nOAuth’ Attack Route — To be fair, Microsoft isn’t completely innocent, as it took a case like this to really have them sharpen their guidance from a bit of a softer stance, but this is not really a technical flaw. I suppose we can’t blame others for not wanting to write articles about developers using anti-patterns.

The real flaw starts with the security industry letting it’s people down

So how exactly can we move from a technical problem to blaming the security industry as a whole? Microsoft speaks to the real flaw in their blog article – too many developers using anti-patterns in software development for authentication and authorization. We can’t truly blame the developers, as we shouldn’t expect every developer to just magically be an expert at modern authentication. It’s difficult to even get identity practitioners to accurately describe the flows many times, so how can we point the finger at others.

Education is the enemy of anti-patterns, but who has time for that

The anti-pattern word is key here. Anti-patterns are patterns that are common enough to become known, yet go against effective design. In this case, the anti-pattern is developers using the email claim within an ID token to make a “good enough” assessment of who the user is.

Anti-patterns develop when there is a lack of education, which both the security and software development industry are ripe with. We need every application to do more things faster and quicker and always operating in some perpetual state of beta to ship things quicker to beat the competition. And no, we don’t have time to slow down to understand what we are doing. Ship it now, fix it later, which is exactly what has happened in this case.

The silos of security, infrastructure, and development hinder progress

The fact that most organizations still operate with varying degrees of silos is the secret everyone knows about but in most cases chooses to ignore.

For proper modern authentication development, we need developers that cross the boundaries between identity practitioner and coder. While logically most organizations can’t operate in a flat structure, we need to better adapt to remove these silos and let key players straddle the line. These key players need to be architects and engineers and developers who are allowed to cross-collaborate and want to cross-collaborate. If we enter a realm where identity security is dictated instead of collaborated, things rapidly break down.

This collaborative team should be proportionately sized to the organization, but whether you are an identity software vendor (ISV) or an enterprise that develops line-of-business (LOB) applications, you will still greatly benefit from the collaboration around identity implementations within your software.

Ignoring the need for change continues to accrue risk

In the nOAuth case, the organizations selling SaaS applications were not named, and the problem was mitigated behind the scenes. But it’s a case of luck in that the “good team” was first to find the rampant use of these anti-patterns. If things turned out worse, and account takeover has happened, it can become a very fast trip to the loss of consumer confidence and depending on your industry or geopolitical region regulator fines and other penalties, from data exfiltration and exposure. It also instills the fear, uncertainty, and doubt, in the industry, almost as a self-fulfilling prophecy that inhibits the industry to move forward. Imagine if your bank account could simply be taken over by someone spoofing your email address in a claim – it’s a fast route to never modernizing identity and leaving us in our current state of too many accounts, too many passwords, too many ways to authenticate, failing our end users.

Final Thoughts

Start collaborating on identity within your organization across all the silos it touches. Prioritize education, for real this time. Your consumers will thank you for it, even if they don’t know they need to.

About This Posts Featured Image

The chosen photo is the work of Brett Jordan, used under the Unsplash license.

Eric Woodruff
Eric Woodruff

Leave a Reply

Your email address will not be published. Required fields are marked *

Author picture

Writing about all things identity and identity adjacent in the Microsoft ecosystem of Azure AD and Active Directory.

Read More
Mailing List

Subscribe to posts here