I'm trying to understand the practical difference between API permissions and app roles in Microsoft Entra ID. My understanding is that API permissions are configured on an app registration when the application needs to access a resource such as Microsoft Graph, Exchange Online, or another API. However, I'm unclear about when app roles are needed and where they should be configured.
I've created many app registrations for development teams to connect to Azure resources, but I haven't created app roles for any of them. If I build a web application with Guest, User, and Admin access levels, how would I define those roles and assign them to specific users or groups?
2 Answers
To create Guest, User, and Admin access, define those values as app roles on the app registration that represents the application or API being protected. Set whether each role can be assigned to users, groups, applications, or a combination of those.
After the roles are created, open the corresponding enterprise application in Entra ID, go to Users and groups, choose Add user/group, select the user or group, and select the appropriate app role. For example, User A can receive Guest, User B can receive User, and User C can receive Admin. When they sign in, the assigned role is normally included in the token, and the application uses it to enforce access.
The easiest distinction is: API permissions describe what your application is allowed to access in another service. For example, an app might request Microsoft Graph permissions or permissions to call a custom API.
App roles describe what a user or client application is allowed to do within an API or application that you own. You could define roles such as Guest, User, and Admin, then use the role claim in the sign-in token to enforce those permissions in your application.
So an app that only connects to Azure, Microsoft Graph, or another service may not need any custom app roles. Azure RBAC and IAM permissions are separate from both of these concepts.
App roles are included in the token issued for the application, but Entra ID does not automatically enforce what those roles mean inside your code. Your application reads the role claim and decides whether the user can access an admin page, edit data, or perform another operation.
That clears up the missing step. I was looking for the assignments in the app registration, but the individual user or group assignments are made through the enterprise application after the roles have been defined.