Azure Entra External ID - app roles by security groups

Question

I’m working in an Azure Entra External ID (customers) tenant and I’d like some clarification on how group-based app-role assignments behave for application (client credential) flows.

Here’s what I’ve set up so far:

1. I created an API application (Resource) that defines one or more app roles (e.g., Orders.Writer, Orders.Reader).
2. I've created a client API application.
3. I created a security group, assigned one of those app roles to the group via Microsoft Graph, and added my API client’s service principal to that group.
4. When my client app requests an access token using the client credentials flow, the token is issued successfully — but the roles claim is empty.

My goal is that the token for the client app should include the appropriate roles claim based on the app roles assigned to the security group that the app’s service principal belongs to.

Could someone please clarify:

• Does Azure Entra (especially External ID) evaluate group-based app-role assignments for service principals during client credential flows?
• If not, is there a way to make Entra include those roles automatically, or must I assign the app roles directly to each service principal instead of through groups?
• Are there any licensing or feature limitations (e.g., Entra ID P1/P2) that affect this behavior in External ID tenants?
• Any official documentation links or examples demonstrating best practices for this setup would be greatly appreciated.
• Thank you in advance for any insights or confirmation!

Answer 1

Hello Ciprian,

In a client credentials flow, Azure Entra ID does not evaluate group-based app role assignments for service principals to include in the roles claim of an access token. The roles claim will be empty because app roles must be assigned directly to the service principal. 

Why group-based app role assignments do not work for client credential flows

The key distinction lies in the token flow and the security principal involved:

• Users vs. applications: Group-based app role assignments are primarily for granting permissions to human users. When a user authenticates, their group memberships are evaluated to determine their roles, and these are added to the token.
• Service principals: When an application authenticates using the client credentials flow, it acts on its own identity (its service principal), not on behalf of a user. The system only includes claims based on roles directly assigned to that service principal. 

---

How to get roles for your client app

To ensure the client app's access token contains the correct roles, you must assign the app roles directly to the client's service principal, not to a group that the service principal belongs to. 

Steps for direct assignment

1. Grant application permissions: In your client application's registration, grant the necessary application permissions for your API (the "Resource").
2. Assign the app role: An administrator must grant admin consent for the selected application permission. This process directly assigns the app role from the resource API to the client's service principal. You can do this in the Azure Portal via Enterprise applications > [Your client app] > Users and groups. 

---

Licensing and feature limitations

The behavior of app role assignments for service principals in client credential flows is not tied to specific Entra ID P1/P2 licensing tiers. This is a fundamental design aspect of the authentication flow.

• The ability to assign app roles to groups is a standard feature for user accounts.
• The fact that these group assignments are not evaluated for service principal tokens is consistent across different Entra ID plan levels.
• Entra External ID tenants support app roles and groups, but they follow the same behavior for service principals as regular Entra ID tenants. 

---

Official documentation and best practices

• OAuth 2.0 client credentials flow: Microsoft's documentation on this flow explicitly states that permissions are granted directly to the application. It also clarifies that in app-only tokens, the resource enforces authorization based on the roles assigned to the app itself.
• Assigning app roles to applications: The documentation for app roles confirms that if you assign an app role to a group that a service principal is a member of, the roles claim will not be added to the issued token.
• Microsoft Graph for assignments: You can use the Microsoft Graph API to programmatically assign app roles directly to a service principal's object. This is an automated way to achieve the direct assignment required for your use case.

Regards,

Raviteja M.