Best Practice Guidance-App Consent

Question

-Best Practice Guidance on App Consent Policies including:

1. Which base permission levels are considered generally ‘safe’ to allow
2. How to safely implement more restrictive policies in an existing environment (particularly with regards to understanding impact to existing consents granted by users).

Answer 1

Hi,

Microsoft recommends choosing the out-of-the-box option where users are only allowed to consent to apps from verified publishers, and only for chosen, lower risk permissions. For additional granularity, admins can also create custom consent policies, which dictate the conditions for allowing users to grant consent, including for specific apps, publishers, or permissions.

The above recommendation comes from this article "Microsoft delivers comprehensive solution to battle rise in consent phishing emails"

Configure how end-users consent to applications
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/configure-user-consent?tabs=azure-portal

Grant tenant-wide admin consent to an application
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/grant-admin-consent#:~:text=%20To%20grant%20tenant-wide%20admin%20consent%20to%20an,you%20agree%20with%20the%20permissions%20the...%20More%20

Answer 2

Hi KathyKim,

If you care about your data, then the only scopes that I would consider broadly safe are graph openid, profile, email and/or User.Read (all delegated only, and assuming that your directory data for users doesn't contain sensitive information). These scopes will enable Single-Signon, which is a very good thing for an organisation.

Anything beyond this will allow a 3rd party to access your data, and your exposure is now dependent on a) what data is accessible by the user, b) the security posture of the third party and c) what trust/legal relationship you have with that third party. You should examine closely what checks Microsoft applies when granting verified publisher status if you are going to rely on that - I doubt that it weighs very much to these concerns.

If you are in an organisation where you don't have complete/centralised ownership over all files, and/or if you don't have visibility to what data is being stored, then tenant-wide admin consent to scope beyond these OIDC scopes is generally bad, as you don't actually know what the exposure is. Allow end-users to make informed consent and don't presume to act on their behalf if you don't have the authority over the data. The one exception I would make is second party (Microsoft) owned platforms that integrate closely as part of the o365 ecosystem. But this definitely doesn't extend to LinkedIn. Also check whether the client platform is covered by Microsoft's security compliance efforts like SOC2 - graph explorer does not and there is no indication of where this is hosted or how it is managed, so I don't endorse graph explorer against the production o365 tenant.

Regards
Ben