Saying “No Thanks” to nOAuth

You may have heard about a vulnerability called, “nOAuth”, where, per Microsoft, “use of the email claim from access tokens for authorization can lead to an escalation of privilege.” What is this vulnerability, how can Okta help, and what are the mitigation steps and strategies to keep your own environment nOAuth free? Let’s break it down!

What is nOAuth?

Discovered in April of 2023, by researchers at descope, the nOAuth vulnerability relies on user accounts being merged by an Microsoft Azure AD OAuth application in a way that allows the attacker to takeover a user account.

The vulnerable condition was observed in several unique combinations of OAuth applications, identity providers, and where “Log in with Microsoft” was offered as a sign-in method. While the research named Microsoft-specific methods of sign-in, we feel there are lessons to be learned by all developers of OAuth apps, irrespective of which identity provider they rely on.

The nOAuth Attack

The attack works like this: adversaries first create a new Azure AD administrator account (in an attacker-owned tenant) and alter its email address to match that of their intended target. There are two unique conditions that must be met for this to result in account takeover.

An OAuth application must:

• Trust the “email” claim for verifying users (which is not a recommended practice), and

• Merge user accounts whenever a user signs-in via “Sign in with Microsoft” (social login). The user must have previously signed into the app using some alternative mechanism to trigger the merge event.

If the application merges user accounts without proper validation, the attacker gains control over the target's application account, even if the victim didn't have a Microsoft account to sign-in with.

While many elements must align for this attack to work, the nOAuth attack is difficult to remedy in that it requires remediative action by both the Identity Provider (in this case, Microsoft) and the vulnerable third-party application.

Got it. What does Microsoft say about all this?

Microsoft released guidance on how to manage the nOAuth vulnerability, including:

• Never use an email claim for authorization purposes.

• Modify the authenticationBehaviors API to reject unverified email claims to mitigate the risk for existing applications.

• When developers are ready to update their code and migrate users to an immutable identifier, like OID, they can use the “xms_edov” claim to verify the email address is verified in the Azure AD tenant before the user identifier is changed.

Microsoft also told customers that it, “deployed mitigations to omit token claims from unverified domain owners for most applications”. As such, given the above advice and mitigations, we’ve mostly reached the end of the nOAuth saga. However, there’s more to consider on the topic, and we’d be remiss (and we hate being remiss) if we didn’t go a bit deeper here, because now that we know the what and how of nOAuth, we can bring the Okta world and philosophy into focus.

Saying “No Thanks” to nOAuth

First off, it's important to note that this vulnerability stems from a misplaced trust in self-asserted email addresses. However, the novel (and alarming) part of nOAuth is that the attack works across Azure AD tenants, rather than being contained within them.

By contrast, the Okta Workforce Identity Cloud (WIC) is architected around per-tenant (“Okta Org”) federation, and it's up to the Org administrator to determine what identifiers to support. Our tenant boundary is strict: an org administrator can't impersonate users in a different org. Our risk lens is even more granular: by using per-application signing keys, administrators can also mitigate risk across application instances, even within a single org.

One easy remediation within Okta's Universal Directory is configuring "primaryEmail" to be a read-only attribute that end users cannot change (see screenshot below).

This attribute can also be sourced from HR or other external systems of record; these are the typical solutions for a workforce deployment.

While Okta Customer Identity offers the option to allow unverified emails to be used as part of Self-Service Registration (see screenshot below); the blast radius is again squarely within the tenant itself.

Furthermore, the issuer of Microsoft tokens is "MicrosoftOnline", whereas for Okta it is your-org.okta.com.

This vulnerability relies on the concept of leveraging a third-party “social login” combined with a reliance on unverified user-controlled input. Okta allows for a much more secure implementation, including detection tools that greatly diminish the opportunity for this type of third-party vulnerability. In general, applications should be verifying JSON Web Token (JWT) claims:

• The iss (issuer) claim matches the identifier of your Okta authorization server.

• The aud (audience) claim should match the Client ID that you used to request the ID Token. This will be the Client ID for the Application you created in Okta.

• The iat (issued at time) claim indicates when this ID token was issued, expressed in Unix time.

• The exp (expiry time) claim is the time at which this token will expire., expressed in Unix time. You should make sure that this time has not already passed.

• The nonce claim value should match whatever was passed when you requested the ID token.

The iss (issuer) must be validated in order to make sure the org that generated the JWT is indeed the correct one.

We’ve also introduced two capabilities to our Customer Identity Cloud (CIC) to reduce the attack surface. For starters, we default to setting the email_verified claim to “false” for users:

CIC has also implemented an email verification flow:

If a customer takes the steps listed above, a nOAuth attack will be stopped at this screen:

This can be a simple (yet effective) way to avoid this type of account takeover. If your application requires that the emails from an Azure AD/ADFS connection's users are always verified, you can enable the “enable email verification” flow during login for Azure AD and ADFS connections option in the tenant's Advanced Settings section.

After the user authenticates for the first time with a non-verified email, CIC will then ask the user to verify their email by entering a one-time-use code that will be sent to their email account. If the user completes this step, the email_verified field will be set to true, and users will not be prompted again for email verification, unless Azure AD or ADFS return a different email for the user.

And there you have it, tools and tips you can use in your Okta environments to help mitigate the nOAuth vulnerability. As always, regularly testing and validating your identity program is a critical step for your overall security health, we hope you’ve found a few things you can implement today.