The nOAuth vulnerability was originally discovered by Descope security team and impacts Microsoft Azure AD applications configured to use OAuth.
Essentially the vulnerability is a design flaw that can lead to account takeover when the application has “Login with Microsoft” button. An attacker may forge its own email address to match a victim address and as a consequence, the application will let the attacker sign in and impersonate the victim user.
For instance, Grafana patched this vuln and assigned CVE-2023-3128. In this demo FusionAuth application will be used as a Proof-of-Concept to demonstrate how to exploit the nOAuth vulnerability. FusionAuth is an Identity and Access Management (IAM) platform designed to simplify the implementation of secure authentication and authorization systems for web and mobile applications.
Setup Azure AD
Start by creating 2 distinct tenants in Azure AD.
noauthuser.onmicrosoft.com- Legitimate tenant
noauthattacker.onmicrosoft.com- Attacker’s tenant
Create one user on each tenant (
Register an application in Azure legitimate tenant. It will be used to configure a new IdP (OpenID) in FusionAuth.
Note that callback URL
http:// is only allowed because the hostname is
localhost. In reality, it would be mandatory to use TLS/HTTPS. The application is configured as multi-tenant for cross-tenant exploitation. Even though single-tenant apps are less likely to be exploited, they might still be vulnerable. As an exercise, reproduce the steps below and combine all the possible configurations for app types in Azure AD (single-tenant, multi-tenant, multi-tenant + personal accounts) & issuer URL authorities (such as
Keep the client ID and client secret. Additionally, assign the respective user (
victim) to access this application in Azure
Enterprise Applications menu. Follow the docs for step-by-step procedure.
Setup the Application
Run the FusionAuth application as a Docker container for convenience. Follow the Docker installation guide.
The local FusionAuth app setup will look more or less like this:
Admin web interface will be available at http://localhost:9011/admin/setup-wizard once the Docker containers are up and running. Proceed to configure a local administrator and then create a new IdP (will use OpenID in this case).
Once it has been configured, the “Login with Azure AD” button should appear below.
After signing in, the error message indicates the user has been successfully registered but doesn’t have access to FusionAuth administrator web interface.
For demonstration purposes we’ll assign
firstname.lastname@example.org to FusionAuth admins group since we don’t have any 3rd-party application configured in FusionAuth.
Going back to the panel as local admin
email@example.com we can assign the
victim user to the admins group.
Finally when we login once again as
victim, we will be displayed the FusionAuth admin web interface.
Now we have a working FusionAuth instance configured to authorize users from Azure AD.
attacker might change his contact email address field in Azure AD to match the
victim address. Once he tries to login, the application will merge the account and let the
attacker login into the
To exploit the nOAuth vulnerability:
Vulnerability was successfully exploited and user
attacker is now authenticated as
Authentication bypass: arbitrary users may log in into the application(s).
Account takeover: the attacker can impersonate and compromise accounts of legitimate users.
Privilege escalation: a regular user can escalate to a more privileged account.
Microsoft suggests the use immutable fields as user identifier, such as
sub (subject) or
oid (object id) claims, as they can’t be modified or tampered. The use of
upn is discouraged as it might change over time but its use does not leave the application vulnerable. A new optional claim
xms_edov was introduced to indicate wheter the email domain owner has been verified.
Also enabling strong authentication mechanisms such as multi-factor authentication (MFA) helps prevent this vulnerability from being successfully exploited. Refer to nOAuth blog by Descope and official Microsoft advisory for more recommendations.
CVSS Severity Score: 7.1 - High
- 2023-08-03: Vulnerability was discovered
- 2023-08-04: Sent vulnerability details to vendor (
- 2023-08-14: The vendor acknowledges the vulnerability
- 2023-08-18: New security enhacements
- 2023-10-21: New public release
- 2023-10-24: Public disclosure