Microsoft introduced the feature Publisher Verification to help administrators to stay on top of all OAuth2.0 apps and avoid illicit content attacks. You can find more details about these topics here:
- Publisher verification
- What is the illicit consent grant attack in Office 365?
Generally, this is a very welcome security feature, but there are also some pitfalls and facts that need to be considered carefully.
First of all, there are many apps out there, which do not meet the requirements. This includes large vendors, which should know better. Similar to the issue of not having a set X-AnchorMailbox header in requests as mentioned in my article EXCHANGE ONLINE MIGRATION: UNMENTIONED PITFALLS (PART 2) (there are still many vendors that have not yet implemented this!).
But it's not only 3rd party vendors that are missing their verification: Microsoft is also not doing a good job, but as these apps are handled by Microsoft itself, they get a special treatment.
Besides the missing requirements, I want to highlight some facts, which are more related to the configuration and therefore important to you as an administrator.
Microsoft mentioned this as a tip in their documentation in Manage permission classifications:
In fact, if you have not configured at least these permissions, users will receive this:
Here's an example:
I have the following permissions configured in my test tenant:
I am missing the permission email! Now I am requesting an auth code from AAD using the following PowerShell code:
As I am missing one required permission, I will see this:
After adding the missing permission to the classification, I can grant consent and can use the code for acquiring an access token.
Note: Don't get confused about the missing verification, as apps using one of the tenants configured domains can be granted consent without having them verified. But they follow the classifications!
If you configure permission like Mail.ReadWrite, do not expect that this includes Mail.Read! You really need to allow every permission, which should be allowed.
Here's an example:
As you can see in the previous screenshot, I configured to allow Mail.ReadWrite. Now I am trying to get a code requesting Mail.Read, which is in fact lower permission and you might to expect that this is included:
This result is the very same result as shown above:
To avoid this end-user experience, make sure you have added ALL permissions that you want your users to be able to grant consent for.
Bear in mind with these topics, when you configure and before you enable verified publisher, it depends on your setup and security concerns what you need to configure, but think about this:
Even when you configure a large number of permissions, these apps need to be verified and need to meet requirements. This might not prevent you from illicit consent, but it's still more secure than allowing users to consent to every app.
Active Directory as the foundation of your network, and the structure that controls access to some of the most critical resources in your organization. ENow uncovers cracks in your Active Directory that can cause a security breach or poor end user experience. In particular, ENow enables you to:
- Report on highly privileged groups (domain admins)