A continuation to my previous post. This is more of me thinking aloud/ summarizing so I have a ready reference for myself.
- RBAC for applications is the new way of granting permissions to application. I allude to this in that post.
- However, RBAC for applications is limited in terms of the permissions it can grant. (Do
Get-ManagementRole | ?{ $_.Name -like "Application*" }to get a list). 
- It is fine as long as you want to act upon users/ mailboxes, it won’t work with groups as those permissions are not available.
- RBAC for applications does not need the Office 365 Exchange Online > Exchange.ManageAsApp permission.
- This requires creating a service principal in Exchange Online (a pointer to the one in Entra ID basically).
- I could be mistaken, but I don’t think I am – this doesn’t need connecting with Exchange Online PowerShell. Graph API is fine (example).
- However, RBAC for applications is limited in terms of the permissions it can grant. (Do
- RBAC for applications replaces application access policies.
- It too supports a limited set of permissions. Similar to RBAC for applications.
- Note it does not need the Office 365 Exchange Online > Exchange.ManageAsApp permission.
- Same as above, Graph API is fine.
- Lastly, you have app-only authentication.
- This requires the Office 365 Exchange Online > Exchange.ManageAsApp permission.
- With this one, after creating the service principal you can assign a role via Entra (e.g. Exchange Administrator).
- Or, you can skip granting any roles in Entra, instead grant it permissions in Exchange Online. This is what I do in my previous post.
- If you go this route, you must create a service principal in Exchange Online (a pointer to the one in Entra ID) (step 2 of the official instructions).
- This requires connecting with Exchange Online PowerShell. (But, I think Graph API will work for the things you can manage via Graph API – e.g. setting out of office. I should update this post once I have a better idea myself).
