Improving Security - Together

SpartanWaycomauThanks for your answer. According to https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#permission-types a service (or daemon) application requires "application permissions" which are given through a "OAuth 2.0 client credentials grant flow" (as per https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow). The "OAuth 2.0 client credentials grant flow" requires a global admin to consent for the whole tenant. According to the https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#permission-types,

For application permissions, the effective permissions of your app will be the full level of privileges implied by the permission. For example, an app that has the User.ReadWrite.All application permission can update the profile of every user in the organization.

Going back to your remark, the scopes in the context of "application permissions" (not "delegated permissions") look like the following ones (as https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow#application-permissions confirms):

• Read mail in all mailboxes
• Read and write mail in all mailboxes
• Send mail as any user
• Read directory data

So, my question to Greg Taylor - EXCHANGE stays the same: Is Microsoft considering the scenario where daemon apps that previously only had a narrow RBAC recipient scope for the EWS App-Impersonation permissions, when Microsoft proposes OAuth 2.0 "application permissions" (with "client credentials grant flow") as replacement? If yes, what should be right setup that global admins must do, in order for a daemon application to not receive the scope e.g. "Read and write mail in all mailboxes", but only "Read and write mail in user's mailbox" (where the <user's mailbox> is defined by the O365 admins)