![]() 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 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |