App Service Easy Auth (authsettingsV2): Does allowedPrincipals use OR logic between identities and groups for service principal tokens?

Root Cause (confirmed in Microsoft docs)

This is not actually a bug in the OR logic itself — it's a side effect of how Microsoft Entra ID issues claims to service principals (which is what a Managed Identity token is) versus user principals.

From the official Microsoft Entra documentation on optional claims:

"Group optional claims are only emitted in the JWT for user principals. Service principals aren't included in group optional claims emitted in the JWT." — Configure and manage optional claims

This means an app-only token from your APIM Managed Identity will never contain a groups claim — period, by design, regardless of what you configure.

Per the Easy Auth allowedPrincipals documentation:

"allowedPrincipals — A group of checks that determine if the principal that the incoming request represents can access the app. Satisfaction of allowedPrincipals is based on a logical OR over its configured properties." — Configure your App Service app to use Microsoft Entra sign-in

So in theory, identities (oid match) should independently satisfy the OR even if groups can't be evaluated. What you're hitting is that Easy Auth's validation engine appears to fail-closed when groups is configured but the incoming token has no groups/hasgroups/_claim_names.groups claim at all (as is always the case for app-only/Managed Identity tokens) — instead of correctly skipping that check and falling through to evaluate identities. This matches what you've already filed as a bug, and is consistent with known reports of this exact interaction.

Is there a supported workaround? Yes — use App Roles instead of Groups

Microsoft's own guidance specifically calls this scenario out. From the Managed Identity best practices docs:

"In both cases, for non-human identities such as Microsoft Entra Applications and Managed identities, the exact mechanism of how this authorization information is presented to the application isn't ideally suited today." — Managed identity best practice recommendations

And from the Easy Auth docs themselves:

"We recommend basing in-app authorization on application roles rather than groups when: you're developing a new application... and support for nested groups isn't required. Using application roles limits the amount of information that needs to go into the token, is more secure, and separates user assignment from app configuration."

The critical difference: the roles claim (App Roles) IS emitted for service principals, unlike the groups claim, which explicitly excludes them. This is exactly the gap you need to close.

Recommended fix

1. Define an App Role on your Logic App's app registration (e.g. LogicApp.Invoke). → Define an app role
2. Assign that role to your Entra ID group (so all group members inherit it) — via Enterprise Applications → Users and groups → Add user/group → select your group → assign the role.
3. Assign the same role directly to the APIM Managed Identity as a service principal — this must be done via Microsoft Graph PowerShell/CLI (the Azure portal UI doesn't support assigning app roles to MIs): → Assign app roles to managed identities
4. Remove allowedPrincipals.groups entirely from your Easy Auth config — replace the group-based check with allowedApplications (if you want to lock by client app) plus your own lightweight roles claim check in code, since Easy Auth's built-in policy engine doesn't have a native "role" check property — only identities and allowedApplications. You'll validate the roles claim by reading the x-ms-client-principal header or the access token (x-ms-token-aad-access-token) in your workflow/function code:

json

// Example: decoded x-ms-client-principal claims will include
{
  "typ": "roles",
  "val": "LogicApp.Invoke"
}

This pattern works identically for both your Managed Identity and your group members, since both now carry the same roles claim — giving you the effective (Managed Identity OR group members) behavior you originally wanted, just implemented via roles instead of groups.

Summary

Yes — keep your feedback item open, since the fail-closed OR behavior with groups + app-only tokens is a legitimate product gap. But for production today, switching to App Roles is the Microsoft-recommended and currently functional path to achieve (Managed Identity OR group members).

References:

• Configure your App Service app to use Microsoft Entra sign-in — Use a built-in authorization policy
• Configure and manage optional claims — groups optional claims
• Managed identity best practice recommendations — Limitation of using managed identities for authorization
• Assign app roles to managed identities