What is On-Behalf-Of Authentication in Microsoft Entra ID?

Understanding the Core Concept

The fundamental purpose of OBO authentication is to propagate a delegated user identity and permissions through a sequence of API calls. When your service desk application needs to perform actions across multiple Microsoft services—such as reading user information from Microsoft Graph and then accessing customer resources in Exchange Online—OBO ensures that all operations occur within the security context of the signed-in user, not the application itself.

This distinction is crucial for MSPs. Unlike application permissions that grant broad access across an entire tenant, OBO uses delegated permissions exclusively. This means your service desk tools can only perform actions that the actual user is authorized to perform, preventing privilege escalation and maintaining strict security boundaries between customer environments.

How the OBO Flow Works

The OBO flow follows a specific sequence of token exchanges. When a client application authenticates a user, it receives an access token (Token A) for the middle-tier API. The client then calls your middle-tier API—such as Ekkie AI's service desk platform—and includes Token A in the request's authorization header.

Your middle-tier service validates Token A and uses it to request a new access token (Token B) from Microsoft Entra ID's token endpoint. This request includes your service's credentials (either a client secret or certificate) and specifies the downstream API as the target. The critical parameter requested_token_use must be set to on_behalf_of to indicate this is an OBO flow.

Microsoft Entra ID validates both the incoming token and your service's credentials. If the user has consented to the necessary permissions and all validations pass, Entra ID issues Token B. Your middle-tier service then uses Token B to make authenticated requests to the downstream API, such as Microsoft Graph or Exchange Online.

Why MSPs Need OBO Authentication

For MSPs managing hundreds or thousands of tickets across multiple customer tenants, OBO authentication provides several essential capabilities. First, it ensures that every action taken by your service desk automation respects the permissions of the actual user making the request. An engineer resolving a ticket for Customer A cannot inadvertently access resources belonging to Customer B, even when using the same automation tools.

Second, OBO maintains full auditability. Since the original user's identity flows through every API call, all actions appear in Microsoft 365 audit logs as performed by that specific user, not by a generic service account. This creates clear accountability and simplifies compliance reporting.

Third, OBO enables sophisticated workflows where your service desk application coordinates actions across multiple Microsoft services while maintaining consistent security context. For instance, Ekkie AI can use OBO to validate a user's permissions in Microsoft Graph, then create a shared mailbox in Exchange Online, all while ensuring the requesting engineer has appropriate access in both systems.

Delegated Permissions vs. Application Permissions

A critical aspect of OBO authentication is its exclusive use of delegated permissions. When configuring your application in Microsoft Entra ID, you must request delegated scopes, not application roles. Delegated permissions create an intersection between what the application is allowed to do and what the user is authorized to do. The effective permission is always the more restrictive of the two.

This design prevents scenarios where a user could gain access to resources beyond their normal authorization simply by routing requests through your application. Even if your application has been granted broad delegated permissions, a user with limited privileges cannot perform actions they normally couldn't perform directly.

Implementation Considerations for MSPs

When implementing OBO flows in your MSP environment, Microsoft strongly recommends using the Microsoft Authentication Library (MSAL) rather than coding the OAuth protocol manually. MSAL abstracts much of the complexity and provides methods specifically designed for OBO scenarios.

Your middle-tier application must be registered as a confidential client in Microsoft Entra ID, with either a client secret or certificate credential. Single-page applications (SPAs) cannot directly participate in OBO flows because they cannot securely store credentials; instead, they should pass access tokens to a middle-tier confidential client that performs the OBO exchange.

Consent management is another critical consideration. The user (or a tenant administrator) must consent to the delegated permissions your application requests. For MSP scenarios where engineers access multiple customer tenants, you can streamline consent using the .default scope combined with known client applications in your app manifest, enabling combined consent flows that prompt users once for all required permissions.

Security and Compliance Benefits

OBO authentication aligns perfectly with zero-trust security principles. By maintaining user identity throughout the request chain, OBO ensures that Conditional Access policies continue to apply even when requests pass through your middle-tier services. If a downstream API requires multi-factor authentication (MFA), the middle-tier service will receive an error response that can be surfaced back to the client, prompting the user to satisfy the MFA requirement.

For MSPs working with security-conscious customers, OBO provides clear separation between your automation capabilities and user permissions. Your service desk platform gains no special privileges; it simply acts as a trusted intermediary that preserves and propagates user identity through complex workflows.

This approach is fundamental to how platforms like Ekkie AI maintain security while providing powerful automation capabilities. When an engineer uses Ekkie Chat to create a user account in a customer tenant, the OBO flow ensures that the action is both executed with the engineer's delegated permissions and logged against their identity in the customer's audit trail. This maintains compliance, accountability, and customer trust while still enabling efficient ticket resolution.

Practical Application in Service Desk Workflows

In real-world MSP operations, OBO authentication enables sophisticated multi-step workflows that would otherwise require complex credential management or excessive application permissions. An engineer resolving a mailbox access ticket can use a single interface to verify the user exists in Entra ID, check their mailbox permissions in Exchange Online, and update group memberships—all while the system maintains their identity and respects their access level in each customer tenant.

The combination of OBO authentication with modern service desk platforms creates a controlled execution environment where AI can prepare actions, engineers can review and approve them, and the actual execution respects all security boundaries. This balance between automation and control is what enables MSPs to scale efficiently without compromising security or compliance.

Understanding On-Behalf-Of authentication is essential for MSPs building or adopting modern service desk tools. It provides the foundation for secure, auditable, multi-tenant operations that maintain user identity and permissions across complex Microsoft 365 environments while enabling the automation necessary for efficient ticket resolution at scale.