I'm hoping to get some help with understanding why a permission like Mail.ReadBasic.All is not made available as a Delegated Permission. The use case in my head is that of administrators. For example, an Exchange Admin would like to review the contents of a user's mailbox. This could be the message headers on a certain message, or it could be all messages for a task like summarizing the mailbox's consumption by year. The only options for the administrator currently are:
A) Delegated permission Mail.Read.Shared + FullAccess granted from the necessary mailbox.
B) Application Permission Mail.ReadBasic.All, and the administrator pretends he/she is an application, and auditing fidelity is lost.
Both options seem inferior to the hypothetical option C:
C) Delegated permission Mail.ReadBasic.All
Is the reason simply the design of OAuth2 from the ground up is so that Delegated permissions are limited to true self-service? If that is the case, then maybe option B really isn't all that bad from a security standpoint, just the lost auditing accuracy is still an issue.
Please help me understand this. I am used to taking advantage of application permissions for my unattended scripting needs. But as I move over to MS Graph for my interactive (administrator) needs, I find this gap strange.
I believe I may have come up with the reason why it was chosen to NOT offer Mail.ReadBasic.All as a Delegated Permission. It may not be possible to supply the requesting user with the equivalent permission via RBAC role. The closest thing I can think of that would accomplish it would be the ApplicationImpersonation role in Exchange, which would be more permissions than we want in this scenario (re: Mail.ReadBasic.All).
It makes me think that however the Effective Permissions are made possible for Application Permissions, that same capability could stand to be available for some special case Delegated Permissions (like Mail.ReadBasic.All).