If you have enabled support for multi-tenant authentication for your registered application in Azure AD then please read the following information carefully.
The Descope security team discovered a gray area in Microsoft Azure AD multi-tenant OAuth applications that could lead to full account takeover.
Please compare your configuration with the example below, if you are not sure whether you have enabled support for multi-tenant authentication.
The Descope team has published the following blog post informing about this issue and it goes without saying that reading it is highly recommended: https://www.descope.com/blog/post/noauth.
Continue below with reading what you should do to remediate this issue.
Remediation steps
As Microsoft suggests in their claims validation documentation, upn, email, preferred_username and other claims should not be used to make authentication or authorization decisions. The claim that should be used as the unique identifier for the user is the sub (Subject) claim.
Unfortunately, at the moment WPO365 heavily relies on the upn, email and preferred_username claim and does not offer support for the sub claim. However, it does support the oid claim, which is also not mutable and contains verified information (namely, the Azure AD Object ID of the user).
I therefore strongly recommend that you update the Order for matching users (on WPO365’s Single Sign-on page) and remove all claims but leave the oid claim, as illustrated in the following image.
Please note that this is currently a premium option, but so is support for multi-tenant authentication and therefore this option should be unlocked for anyone who is directly affected by this flaw.
Even though this flaw primarily affects those sites that enabled support for multi-tenant authentication, it is still a good idea for single tenant configuration as well, to reduce the list of claims used to match users to the oid claim.
WordPress users that were created by WPO365 are automatically tagged (since version 18.0 that was released around 1.5 years ago) with their Azure AD Object ID when:
- They interactively sign in with Microsoft
- They were created with the help of WPO365 User synchronization.
Possible implications of changing the order for matching users are:
- Existing users that never signed in with Microsoft into your WordPress site and that were not created by WPO365’s User synchronization feature are not tagged with their Azure AD Object ID and can therefore not sign in with Microsoft.
If an existing user, who is not tagged with an Azure AD Object ID, signs in with Microsoft, may trigger WPO365 to try and create a new WordPress user. However, if the email address of that user is already in use, then WPO365 will obviously fail to create the new user.
Next steps
In the end of August, WPO365 will see a new release that allows administrators to configure what claim WPO365 should take for a WordPress username (and to use to match users) e.g. the sub claim. This will further help to reduce WPO365’s dependency on the user’s preferred_username claim.
Also the premium lock on the option to change the order for matching users will be removed. This will help ensure that everyone can continue to enjoy the benefits of signing with Microsoft in a safe and trustworthy manner.
Please accept my apologies for this inconvenience and don’t hesitate to contact me e.g. via the online contact form https://www.wpo365.com/contact/ in case of any questions and feedback. I am here to help!