This chapter covers App Roles and Role-Based Access Control (RBAC) in Microsoft Entra ID (formerly Azure Active Directory), a critical topic for the AZ-204 exam. Understanding how to define, assign, and validate app roles is essential for securing custom applications and APIs. This topic area typically accounts for 5-10% of exam questions, often appearing in scenarios involving authorization design, token validation, and integration with Azure AD. Mastery of app roles ensures you can implement fine-grained access control in your applications.
Jump to a section
Imagine a large corporate building with multiple floors and secure areas. The building issues badges to employees, each badge containing a role like "Executive," "Engineer," or "Visitor." At each door, a badge reader checks the role against an access control list (ACL) for that door. For example, the server room door allows only "Engineer" and "Executive" roles. When an employee swipes their badge, the reader reads the role, looks up the door's ACL, and either unlocks or denies. The badge itself doesn't contain permissions for every door; it just carries the role. The door's ACL defines which roles are allowed. This is exactly how app roles work in Microsoft Entra: an application defines roles and assigns them to users or groups. The user's token includes the role claim, and the app's authorization code checks that claim against its own rules. The role is just a string; the app decides what that role can do. If an employee's role changes (e.g., promoted to Executive), the badge is re-issued with the new role. Similarly, when a user's app role assignment changes, they receive a new token with the updated role claim. The building doesn't need to know every employee's name; it just needs to know their role and the door's ACL. This decouples identity from authorization, making it scalable and manageable.
What Are App Roles?
App roles are a mechanism in Microsoft Entra ID that allow you to define roles for an application and assign them to users, groups, or service principals. When a user authenticates to your application, their token includes a roles claim containing the assigned role(s). Your application's code then uses these claims to authorize access to specific features or resources. App roles are a form of Role-Based Access Control (RBAC) at the application level, distinct from Azure RBAC which controls access to Azure resources.
Why App Roles Exist
Before app roles, developers often implemented their own authorization logic using custom claims or database lookups. This was error-prone and hard to manage at scale. App roles standardize authorization by leveraging Entra ID's identity infrastructure. They allow you to:
Centralize role management in Entra ID instead of per-application.
Assign roles to users or groups, simplifying administration.
Use roles in tokens, eliminating the need for app-to-directory calls for every authorization check.
Support dynamic role assignments via group membership.
How App Roles Work Internally
Define roles in app registration: In the Azure portal, under your app registration, you define app roles with a display name, value, description, and allowed member types (Users/Groups or Applications). The role value is a string that appears in the token.
Assign roles: Roles are assigned to users, groups, or service principals via the Azure portal, Microsoft Graph API, or PowerShell. When assigned to a group, all members of the group inherit the role.
Token issuance: When a user authenticates, Entra ID includes a roles claim in the access token if the user (or their group) has any app role assignments. The claim contains an array of role values.
Token validation: Your application validates the token (signature, issuer, audience, etc.) and extracts the roles claim. Your authorization logic then checks if the required role is present.
Authorization decision: Based on the role, the application grants or denies access to specific endpoints or features. This is typically done using attributes like [Authorize(Roles = "Admin")] in ASP.NET Core.
Key Components and Defaults
Role Value: A string that uniquely identifies the role within the app. Example: "Admin", "Reader". This value appears in the roles claim.
Allowed Member Types: Can be Users/Groups or Applications. If set to Applications, the role can be assigned to service principals (useful for daemon apps).
Role ID: A GUID assigned to each role, used internally.
Token Claim: The roles claim is a JSON array of strings. For example: "roles": ["Admin", "Manager"].
Group Assignment: Roles assigned to groups are inherited. However, there is a limit of 200+ group memberships that can be included in a token. If a user is a member of more groups than the limit, the hasgroups claim is set to true and the groups claim is omitted. In such cases, you must use the Microsoft Graph API to retrieve group memberships.
Token Lifetime: Access tokens have a default lifetime of 60-90 minutes (configurable). If role assignments change, the user must obtain a new token (by logging out/in or after token expiry) for the changes to take effect.
Configuration Steps
#### Define App Roles (Azure Portal)
1. Navigate to Azure Active Directory > App registrations > Select your app. 2. Click on "App roles" under "Manage". 3. Click "Create app role". - Display Name: e.g., "Administrator" - Allowed member types: Choose "Users/Groups" or "Applications" - Value: e.g., "Admin" (this is the claim value) - Description: e.g., "Full access to all features" - Do you want to enable this role?: Yes 4. Click Apply.
#### Assign Roles (Azure Portal)
Go to Enterprise applications > Select your app.
Click "Users and groups".
Click "Add user/group".
Under "Users and groups", select users or groups.
Under "Select role", choose the app role.
Click Assign.
#### Assign Roles via Microsoft Graph API
POST https://graph.microsoft.com/v1.0/users/{user-id}/appRoleAssignments
Content-Type: application/json
{
"principalId": "{user-id}",
"resourceId": "{service-principal-id}",
"appRoleId": "{role-id}"
}#### Validate Roles in Code (ASP.NET Core)
[Authorize(Roles = "Admin")]
public IActionResult AdminOnly()
{
return Ok();
}Or programmatically:
var roles = User.Claims.Where(c => c.Type == "roles").Select(c => c.Value);
if (roles.Contains("Admin"))
{
// Allow
}Interaction with Related Technologies
Azure AD B2C: App roles are not natively supported in Azure AD B2C. Instead, you use custom attributes and claims transformation.
Managed Identities: Managed identities can be assigned app roles, allowing Azure resources to authenticate and access APIs with specific roles.
OAuth 2.0: App roles are carried in the access token as a claim. They are part of the OAuth 2.0 authorization framework, not the authentication flow.
Common Pitfalls
Token not containing roles: Ensure the user or group has been assigned the role. Also, check that the token is requested with the correct scope (usually access_as_user).
Group assignment limit: If a user belongs to many groups, the token may not include the groups claim. Use the hasgroups claim to detect this and call Graph API.
Role value mismatch: The role value in code must exactly match the value defined in the app registration (case-sensitive).
Exam Tips
App roles are for application-level authorization, not Azure RBAC.
Roles can be assigned to groups to simplify management.
The roles claim is only present if the user has at least one role assignment.
For daemon apps, use app roles with allowed member type "Applications".
When using group assignments, be aware of the group membership limit for tokens.
Define App Roles in Registration
In the Azure portal, navigate to your app registration under Azure Active Directory. Under 'Manage', select 'App roles'. Click 'Create app role' and fill in the display name, allowed member types (Users/Groups or Applications), value (the string that will appear in the token), and description. Ensure the role is enabled. Each role gets a unique ID (GUID). This step creates the role definition that Entra ID will use when issuing tokens.
Assign Roles to Users or Groups
Go to 'Enterprise applications' in Azure AD, select your application, then 'Users and groups'. Click 'Add user/group', select the users or groups, and choose the app role to assign. You can assign multiple roles to the same principal. Assignments are stored in the directory as appRoleAssignment objects. When assigning to a group, all current and future members inherit the role.
User Authenticates and Receives Token
When a user signs in to your application, they are redirected to Entra ID's authorize endpoint. After authentication, Entra ID checks the user's direct and group-based app role assignments. It then generates an access token that includes a `roles` claim containing an array of role values. If the user has no roles, the `roles` claim is omitted. The token is returned to the application.
Validate Token and Extract Roles
Your application validates the access token by checking its signature, issuer, audience, and expiration. Then, it extracts the `roles` claim from the token's payload. In ASP.NET Core, this is automatically done by the JWT bearer middleware, which populates the User principal with role claims. You can access them via `User.Claims` or the `[Authorize]` attribute.
Authorize Access Based on Roles
Using the extracted role claims, your application's authorization logic determines whether the user can access a resource. For example, an API endpoint might require the 'Admin' role. If the user's roles include 'Admin', access is granted; otherwise, a 403 Forbidden response is returned. This step implements the actual access control.
Enterprise Scenario 1: Multi-tier SaaS Application
A SaaS company offers a project management tool with three tiers: Free, Pro, and Enterprise. They define app roles named 'FreeUser', 'ProUser', and 'EnterpriseUser'. When a user subscribes, the provisioning system assigns the corresponding role to the user via Microsoft Graph API. The application's API checks the roles claim to determine which features to unlock. For example, Pro users can access Gantt charts, while Enterprise users get admin analytics. This approach centralizes license management in Entra ID, eliminating the need for a custom database of user tiers. However, a challenge arises when a user upgrades from Free to Pro: the token must be refreshed. The application handles this by prompting the user to re-authenticate after a plan change. At scale, with millions of users, the group membership limit can become an issue. The company mitigates this by using dynamic groups based on user attributes rather than assigning roles to individual users.
Enterprise Scenario 2: Internal API with Daemon Clients
A financial institution has an internal API that processes transactions. They have two client applications: a web app (user-facing) and a batch processing service (daemon). The API defines app roles: 'TransactionReader' and 'TransactionWriter'. The web app is assigned 'TransactionReader' for users who need to view transactions. The daemon service (a service principal) is assigned 'TransactionWriter' because it needs to write transactions. The daemon authenticates using client credentials flow and receives a token with the 'TransactionWriter' role. The API validates both the user and the role. Misconfiguration occurs when the daemon is accidentally assigned 'TransactionReader' instead — it fails to write transactions. The team uses Azure Monitor to log authorization failures and alerts when a daemon receives a 403.
Scenario 3: Group-Based Role Assignment
A large enterprise with thousands of employees uses Azure AD groups to manage access. They create a group 'HR_Admins' and assign the 'Admin' app role to the group. New HR employees are added to the group and automatically get the role. However, the token size limit (200 groups) is reached for a user who belongs to many groups. The application must handle the hasgroups claim and use Graph API to retrieve group memberships for over-limit users. The solution uses a caching layer to reduce Graph API calls.
What AZ-204 Tests on App Roles (Objective 3.1)
The exam focuses on implementing authentication and authorization by using Microsoft Entra ID. Specifically, you need to know how to:
Define app roles in an app registration.
Assign app roles to users, groups, or service principals.
Validate app roles in an application (e.g., using [Authorize] attribute).
Differentiate between app roles and Azure RBAC roles.
Understand token claims related to roles and groups.
Common Wrong Answers
Confusing app roles with Azure RBAC roles: Candidates often think app roles control access to Azure resources (like VMs). In reality, app roles are for application-level authorization. The exam will have questions where you need to choose between assigning an Azure RBAC role vs. an app role.
Assuming roles are automatically included in tokens: Many think that once a role is defined, it appears in every token. Actually, the roles claim is only included if the user has been assigned the role. If no assignment, the claim is absent.
Using Azure AD B2C for app roles: Azure AD B2C does not support app roles natively. The exam may ask how to achieve role-based access in B2C — the answer involves custom attributes and claims transformation.
Ignoring group membership limits: Candidates forget that tokens have a maximum number of groups (200). If a user exceeds this, the groups claim is omitted and hasgroups is true. You must handle this by calling Graph API.
Specific Numbers and Terms
Group membership limit: 200 groups per token (for Azure AD). For Azure AD B2C, it's limited as well.
Token default lifetime: 60 minutes (configurable).
Role value: case-sensitive string.
Allowed member types: Users/Groups or Applications.
The roles claim is an array of strings.
Edge Cases and Exceptions
Service principal roles: When assigning roles to a service principal (daemon app), the allowed member type must be 'Applications'.
Group-based assignment and token refresh: If a user is added to a group with a role, they won't have the role in their token until they obtain a new token.
Multiple roles: A user can have multiple roles; the roles claim will contain all of them.
How to Eliminate Wrong Answers
If the question is about controlling access to an Azure resource (e.g., a storage account), the answer is Azure RBAC, not app roles.
If the question is about controlling access to a custom web API's endpoints, the answer is app roles.
If the token validation code checks for a claim named 'roles', it's app roles.
If the scenario involves a daemon app, look for 'client credentials flow' and app roles assigned to the service principal.
App roles are defined in the app registration under 'App roles'.
Role values are case-sensitive strings that appear in the 'roles' claim.
Roles can be assigned to groups; members inherit the role.
The 'roles' claim is only present if the user has at least one role assignment.
Token group membership limit is 200 groups; beyond that, use Graph API.
For daemon apps, use app roles with allowed member type 'Applications'.
App roles are not supported in Azure AD B2C; use custom attributes instead.
Role assignments require a new token to take effect.
Use [Authorize(Roles = "RoleName")] in ASP.NET Core to enforce roles.
Distinguish app roles from Azure RBAC roles on the exam.
These come up on the exam all the time. Here's how to tell them apart.
App Roles (Application RBAC)
Used for authorization within an application (e.g., API endpoints).
Defined in app registration under Azure AD.
Assigned to users, groups, or service principals via Azure AD.
Token contains 'roles' claim with role values.
Managed via Azure AD blade or Microsoft Graph API.
Azure RBAC Roles
Used for authorization to Azure resources (e.g., VMs, storage).
Defined at subscription, resource group, or resource scope.
Assigned to users, groups, or service principals via Azure RBAC.
Token contains 'wids' claim (for directory roles) or Azure RBAC uses separate ARM calls.
Managed via Azure RBAC blade or Azure CLI.
Mistake
App roles are the same as Azure RBAC roles.
Correct
App roles control access to application features, while Azure RBAC controls access to Azure resources. They are separate systems with different assignment scopes and token claims.
Mistake
Assigning a role to a group automatically adds the role to existing tokens immediately.
Correct
Token claims are based on the token's issuance time. Users must obtain a new token (by logging out/in or waiting for token expiry) to see the new role.
Mistake
The 'roles' claim is always present in access tokens.
Correct
The 'roles' claim is only included if the user has at least one app role assignment. If no roles are assigned, the claim is omitted entirely.
Mistake
App roles can be used in Azure AD B2C.
Correct
Azure AD B2C does not support app roles. Instead, you must use custom attributes and claims transformation to implement role-based access.
Mistake
You can assign app roles to any security principal, including users, groups, and service principals, without any restrictions.
Correct
When defining an app role, you must specify allowed member types. Roles defined with 'Users/Groups' cannot be assigned to service principals, and vice versa.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
First, ensure the app role definition has allowed member types set to 'Applications'. Then, go to Enterprise applications, select your app, click 'Users and groups', add the service principal, and assign the role. Alternatively, use Microsoft Graph API: POST /servicePrincipals/{id}/appRoleAssignments with the appRoleId and resourceId.
The 'roles' claim is only included if the user has at least one app role assignment for the application. Check that the user (or their group) has been assigned the role. Also, ensure the token was requested for the correct application (audience). If using group-based assignment, verify the group membership and that the token isn't cached.
No, Azure AD B2C does not support app roles. Instead, you can use custom user attributes and define claims transformations in the B2C user flow to implement role-like behavior. Alternatively, you can store roles in a custom database and look them up after authentication.
App roles control access to an application's features (e.g., 'Admin' role in a web app). Azure RBAC controls access to Azure resources (e.g., 'Contributor' role on a storage account). App roles appear in the token's 'roles' claim; Azure RBAC uses separate Azure Resource Manager calls. They are independent.
If a user belongs to more than 200 groups, the token will not include the 'groups' claim. Instead, the 'hasgroups' claim will be set to 'true'. In your application, check for 'hasgroups' and if true, use Microsoft Graph API to retrieve the user's group memberships (GET /users/{id}/memberOf). Cache the results to reduce API calls.
Yes, a user can have multiple app role assignments. The token's 'roles' claim will contain an array of all assigned role values. Your application can check for the presence of any required role.
Role assignments are evaluated at token issuance. To force a new token, you can revoke refresh tokens or set a short token lifetime. Alternatively, you can implement a custom claim check that calls Graph API to get current assignments, but this defeats the purpose of using tokens.
You've just covered App Roles and Role-Based Access in Entra — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?