Enterprise Authorization Methods - Simple Use of Entra ID On-Behalf-Of Flow

Knowledge point: How many authorization methods does Entra ID support?

1. Role-Based Access Control (RBAC)

   • Controls access of users/groups/applications to resources through built-in roles (e.g., Global Administrator, User Administrator, Application Administrator) or custom roles.
   • Commonly used for managing Azure resources and Entra ID itself.

2. Group-Based Authorization

   • Users are assigned to security groups or Microsoft 365 groups, which are then granted access to applications or resources.
   • Applications can use Graph API to retrieve user group memberships to make authorization decisions.

3. Application Permissions & Delegated Permissions

   • In OAuth 2.0 / OpenID Connect scenarios:
     • Delegated permissions: Access resources on behalf of the signed-in user (requires user consent).
     • Application permissions: The application itself (daemon or backend service) directly accesses resources without a user login.

4. Conditional Access

   • Controls access based on conditions (user group, device state, network location, risk level, etc.).
   • Essentially a fine-grained access control policy.

5. Claims-Based Authorization

   • Applications parse claims in the ID Token / Access Token (e.g., roles, groups, scp) to determine if a user is allowed to access certain functions.
   • Often used for fine-grained authorization in custom applications.

6. Attribute-Based Access Control (ABAC)

   • Uses custom security attributes or resource tags, combined with conditional access and RBAC, to implement flexible policies.
   • A newer Entra ID feature to complement RBAC limitations.

Getting Started – Scenario

A user logs in on Web A. To perform a task, Web A needs to call Middleware B, which in turn calls Remote Service C. After execution, the results are returned to the user.

Analysis

1. This is a scenario where the user’s identity and permissions need to extend to C.
2. How can user authorization be passed to C without being impersonated?
3. From C’s perspective, there are two cases, corresponding to two solutions:
   • C does not care about the specific user, only whether B is allowed to call it — Application Permission + Delegation model
   • C cares about the specific user and also whether B has permission to call it — On-Behalf-Of Flow (OBO) user delegation model

Architecture Diagram

Application Permission + Delegation Pattern

On-behalf-of-flow (OBO) User Delegation Pattern