To discover if your app is vulnerable to this issue (and how to fix it), refer to the “Suggested remediation steps” section of this blog.įamiliarity with the terms below will help you better understand the nOAuth configuration issue.
As a result, all of their customers using “Log in with Microsoft” would have been vulnerable. In this instance, merging the attacker account with a legitimate user account would hand full control over the user account to the attacker. We also informed two authentication platform providers that were merging user accounts when “Log in with Microsoft” was used on an existing user account. We informed several large applications that were vulnerable to this tactic, including a design app with millions of monthly users, a publicly traded customer experience company, and a leading multi-cloud consulting provider. These features will enable apps to verify whether an email claim contains a domain-verified email address and redact email claims when the email domain is unverified. We informed Microsoft of the issue and they have since then refactored their documentation, providing stronger guidance and dedicated sections on claim verification.Īs part of Descope’s collaboration with Microsoft on addressing this issue, Microsoft is introducing two new claims to mitigate cases when nOAuth is used for cross-tenant spoofing. Previous Microsoft documentation on this matter recommended not to use the email address as the unique identifier. The combined effect of the points above allows an attacker that created their Azure AD tenant to use “Log in with Microsoft” with a vulnerable app and a specially crafted “victim” user, resulting in a complete account takeover. In Microsoft Azure AD, the email claim is both mutable and unverified so it should never be trusted or used as an identifier.Ī bad actor can change the Email attribute under “Contact Information” in the Azure AD account to control the “email” claim in the returned identity JWT. Using the email claim as the user identifier becomes an issue when this claim is mutable, which is why most IdPs advise against using email as an identifier. Most IdPs provide the common (yet non-standard) “email” claim. NOAuth is an authentication implementation flaw that can affect Microsoft Azure AD multi-tenant OAuth applications.Īccording to the OAuth specification, the user is uniquely identified by the “sub” (subject) claim. Read on to understand how this configuration issue arises, its impact, and suggested remediation steps. Reach out to our security team if you believe your app is vulnerable to nOAuth and need assistance. We are naming this configuration issue “nOAuth” because even the bleakest of days has some room for wordplay. This blog will cover how the Descope security team discovered a gray area in Microsoft Azure AD OAuth applications that could lead to full account takeover.
0 kommentar(er)
