Everything you need to know about the nOAuth Microsoft Azure AD vulnerability

On June 20, 2023, Descope published its discoveries on a new vulnerability—which they named nOAuth—that could lead to a full account takeover of Microsoft Azure AD OAuth applications. The vulnerability was a combination of a flaw in Azure AD and poorly integrated third-party applications.

In this article, we will examine how this vulnerability came to be and how you can ensure your app is not affected.

What is OAuth?

Before we talk about nOAuth, let’s talk a bit about OAuth so you can better understand what’s the problem with Microsoft’s OAuth implementation. Feel free to skip this section if you are already familiar with things like scopes and access tokens.

‍OAuth—short for Open Authorization—is the de facto authorization standard for granting app A access to app B resources on a user's behalf without sharing their password. Every time you sign in to a website using Google and agree to share your email or allow them access to your Google Calendar, you are using OAuth.

During the sign-in process, the identity provider (in this example, Google) will list the resources the other app is asking to access and ask if you are ok with that. This screen will look something like this:

In OAuth terminology these two requested actions are called scopes and they are used to limit an application’s access to a user’s account. An application can ask one or more scopes and the user will have to review them and agree to grant them.

After that the granting application (e.g., Google) will issue what we call an access token that will include this info. An access token looks like a string but contains information in JSON format (aka JWT) that can be read when decoded. It consists of a header, a body and a signature. A decoded body looks like this:

	
{
  "sub": "550e8400-e29b-41d4-a716-446655440000",
  "email": "hgranger@hogwarts.example",
  "aud": "super-app",
  "iss": "your-sass-app",
  "exp": 1703699468,
  "scope": "read-email read-appointments"
}
	

• sub contains the subject of the JWT, for example, a user ID.
• email contains the user’s email.
• aud contains the recipient for which the JWT is intended.
• iss contains the issuer of the JWT.
• exp contains the time after which the JWT expires.
• scope contains the permissions that the user gave.

All these are called claims and they are pieces of information about the user. What we saw is just an example, there are more claims (standard and custom ones).

Let’s see now what’s the problem with Microsoft’s OAuth implementation.

What is nOAuth?

As we saw earlier two of the claims an access token contains are sub and email. According to the OAuth specification, the user is uniquely identified by the sub (subject) claim. Some providers use the email but this is not advisable since a user’s email can be mutable and/or unverified. In Microsoft Azure AD, the email claim is both mutable and unverified so it should never be trusted or used as an identifier. However, some third-party integrations did exactly that. They used the mutable and unverified email as an identifier. And this is how the nOAuth vulnerability came to be.

An attacker can change the email attribute under “Contact Information” in the Azure AD account. This allows them to control the email claim in the returned identity JWT, and consequently, use “Log in with Microsoft” with a vulnerable app (i.e., an app that uses the email address as a unique identifier) and a specially crafted “victim” user. If the app merges user accounts without validation, the attacker now has full control over the victim’s account, even if the victim doesn’t have a Microsoft account. The result? A complete account takeover.

What did Microsoft do?

As a reponse to the disclosed vulnerability, Microsoft updated their documentation, providing stronger guidance on claim verification. They already recommended not to use email as a unique identifier but they updated their docs to provide stronger guidance.They also introduced two new claims to mitigate cases where nOAuth is used for cross-tenant spoofing:

• xms_edov: a claim that enables apps to verify whether an email claim contains a domain-verified email address.
• RemoveUnverifiedEmailClaim: an authentication behavior flag that can redact email claims when the domain for the email is unverified.

How can you mitigate nOAuth?

The first rule is: never use the email claim to make authentication or authorization decisions. The claim that should be used as the unique identifier for the user is the sub claim.

If you wish to continue merging user accounts, always verify that the email is controlled by the real account holder by using other secure means, like a magic link. To learn more about identity linking and how to do it safely see Lessons in safe identity linking.

You can also use the two new claims introduced by Microsoft to explicitly indicate whether an email claim is from a domain-verified email and redact the email claim if needed.

If your app uses “Log in with Microsoft”, you should check whether it is vulnerable to nOAuth asap and remediate accordingly.

How WorkOS protects you from nOAuth?

WorkOS ensures all user emails are unique via an email verification process. By default, email verification is required by all users for authentication to succeed. This ensures that verified users are always returned to your application.

When a user signs in with a new credential for the first time, e.g. they sign in through Google OAuth despite already having a password account, WorkOS will safely attach the new credential to the existing user. This is only performed if WorkOS can verify that the user has access to the email inbox referenced by that credential.

WorkOS considers it a security risk if the user cannot verify their email access. For some identity providers, a credential with an email address does not guarantee access to that inbox.

‍Sign up for WorkOS today and rest assured that we will keep you and your customers safe.