Azure service principal - API permissions vs. AD Role

Question

I have an application that needs to create AD groups and update their memberships via Graph API. I'll be using a service principal to do so.

I'm trying to understand the difference between:

• assigning the service principal to an Azure AD role (for example, "User Administrator": https://docs.microsoft.com/en-us/azure/active-directory/roles/delegate-by-task#groups)
• adding API permissions to the service principal (for example, Microsoft Graph API's "Group.ReadWrite.All": https://docs.microsoft.com/en-us/azure/active-directory/roles/delegate-by-task#groups)

What are the differences here? Do they both effectively give the same permissions?

Answer 1

A built-in role is just a collection of permissions so your answer can be yes. If you grant the same permissions in as a built-in role then you will get the same effective permissions. The "User Administrator" role has the following permissions:

https://docs.microsoft.com/en-us/azure/active-directory/roles/permissions-reference#user-administrator

We created built-in roles to make it easier for users to quickly get role based access control in place. If built-in roles don't meet your needs, you can always create a custom role.

Answer 2

I'm mulling over the same question - which approach is better, MS Graph permissions or built-in roles. I'm leaning towards the built in roles for easier visibility and the potential to assign the permissions to groups.

Unless things have changed very recently you can only create AAD custom roles for a subset of "Application Administrator" permissions - not for any permissions.