Publisher verification and app consent policies are now generally available

This post has been republished via RSS; it originally appeared at: Azure Active Directory Identity Blog articles.

Howdy folks,

 

With usage of cloud apps on the rise to enable remote work, attackers have been looking to leverage application-based attacks, such as consent phishing, to gain unwarranted access to valuable date in cloud services. To protect our customers from such attacks while continuing to foster a secure and trustworthy app ecosystem we're announcing three new updates: 

 

  • General availability of publisher verification
  • User consent updates for unverified publishers
  • General availability of app consent policies

General availability of publisher verification


Last week at Microsoft Ignite, we announced that publisher verification is now generally available. This capability allows developers to add a verified identity to their app registrations and demonstrate to customers that the app comes from an authentic source. We announced public preview at Build in May, and over 700 app publishers have since added a verified publisher to over 1300 app registrations.

 

DBada_0-1602024378764.png


For developers,
publisher verification allows them to distinguish their apps to customers by receiving a “verified” badge that appears on the Azure AD consent prompt.

DBada_1-1602024378773.png

 

Admins can also set user consent policies based on if an apps is publisher verified helping streamline adoption. Developers who are building for Microsoft 365 that want to further distinguish their apps can also participate in the Microsoft 365 App Certification program.

User consent updates for unverified publishers


With publisher verification now generally available, we will be making changes that help protect users from app-based attacks. End users will no longer be able to consent to new multi-tenant apps registered after November 8th, 2020 coming from unverified publishers. These apps may be flagged as risky and will be shown as unverified on the consent screen. Apps requesting basic sign-in and permissions to read user profile will not be affected, nor will apps requesting consent in their own tenants.

To prepare for this change if you are an app developer, add a verified publisher to all your multi-tenant app registrations.

General availability of app consent policies

 

To help admins control what apps their users can consent to, we’re announcing general availability of the new app policies for end user consent. With app consent policies, admins have more controls over the apps and permissions to which users can consent.

Customers can manage settings for user consent by choosing from the following built-in app consent policies in the screenshot below:

 

appconsent3.png

 

Customers can also use Azure AD PowerShell or Microsoft Graph to create custom consent policies for even more control. These policies can include conditions that apply to the app, the publisher, or the permissions the app is requesting. Additionally, custom directory roles now support the permission to grant consent, limited by app consent policies. This can enable scenarios such as delegating the ability to consent only for some permissions, and creating least-privileged automation to manage authorization for apps. 

 

We recommend that customer set their policy to allow user consent for apps from verified publishers and to configure the admin consent workflow to streamline access for end users who are not allowed to consent.

 

As always, we'd love to hear any feedback or suggestions you may have. Please let us know what you think in the comments below. For additional best practices to protect your organization from app-based attacks, be sure to check out the resources below: 

 

 

Best regards,

Alex Simons (Twitter: @Alex_A_Simons)

Corporate Vice President of Program Management

Microsoft Identity Division

 

REMEMBER: these articles are REPUBLISHED. Your best bet to get a reply is to follow the link at the top of the post to the ORIGINAL post! BUT you're more than welcome to start discussions here:

This site uses Akismet to reduce spam. Learn how your comment data is processed.