基于Scope/Role的Azure AD B2C授权支持：微服务架构下跨API调用的Scope授权实现问题咨询

Got it, let's break this down. The core issue here is the fundamental difference between how IdentityServer4 and Azure AD handle permissions for client credential flows—Azure AD strictly separates user-centric permissions and application-centric permissions, which is why you're not seeing scp (Scope) claims in client credential tokens. Here's how to fix this and implement proper authorization:

1. Understand Azure AD's Permission Model for Client Credentials #

Unlike IdentityServer4, Azure AD uses Application Permissions (not delegated scopes) for pure app-to-app authentication (client credential flow). These permissions are returned as roles claims in the token, not scp claims. scp is reserved for delegated permissions (when a user is involved, like in authorization code flow).

2. Configure Application Permissions for API B in Azure AD #

• Log into the Azure Portal, find API B's App Registration.
• Go to API Permissions → Add Permission → My APIs, select API B's app.
• Switch to the Application Permissions tab, create a custom permission (e.g., api-b.full-access) that represents the access API A needs, then add it.
• Critical step: Click Grant Admin Consent (requires a Global Admin or Privileged Role Admin) to activate this permission for all apps in your tenant.

3. Grant API A Access to API B's Application Permission #

• Navigate to API A's App Registration → API Permissions → Add Permission → My APIs, select API B.
• Check the application permission you created (e.g., api-b.full-access) and add it.
• Again, click Grant Admin Consent to finalize the permission grant.

4. Request Tokens with the Correct Scope in API A #

When API A requests a token for API B via client credential flow, use this exact scope value:

api://<API-B-Client-ID>/.default

The /.default suffix tells Azure AD to return all application permissions granted to API A for API B, which will be included as roles claims in the token.

5. Update API B's Authorization Logic to Validate roles Claims #

Using ASP.NET Core as an example, adjust your authorization setup to check for the roles claim:

Configure Authentication #

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"));

Define a Custom Authorization Policy #

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("ApiBAccess", policy =>
        policy.RequireClaim("roles", "api-b.full-access"));
});

Apply the Policy to Your Endpoints #

[ApiController]
[Route("api/[controller]")]
[Authorize(Policy = "ApiBAccess")]
public class SampleController : ControllerBase
{
    // Your API logic here
}

6. Support Both User and App Contexts (If Needed) #

If API B needs to accept both user-initiated requests (with scp claims) and app-to-app requests (with roles claims), create a combined policy:

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("ApiBAccess", policy =>
        policy.RequireAssertion(context =>
            context.User.HasClaim(c => 
                (c.Type == "scp" && c.Value == "api-b.user-access") || // Delegated user permission
                (c.Type == "roles" && c.Value == "api-b.full-access")))); // Application permission
});

This approach aligns with Azure AD's security design, ensuring clear separation between user and application permissions while enabling proper authorization for cross-API calls.

内容的提问来源于stack exchange，提问作者Pinkesh Patel