On-Behalf-Of Authorization

How On-Behalf-Of Authorization Works

On-behalf-of authorization is a delegated decision pattern, not a simple authentication step. The policy decision must consider both the calling service and the original user context, so the service cannot silently widen the user’s intent just because it is technically acting for them. That combined check is what keeps delegation aligned to the upstream request.

In practice, the model is closer to constrained delegation than blind relay. The service may carry the request, but it does not inherit unlimited authority from the user, and it does not get to substitute its own privileges for the user’s intended scope. That distinction matters whenever a workflow crosses trust boundaries or chains multiple systems together.

For the protocol basis of that pattern, the most direct reference is RFC 8693: OAuth 2.0 Token Exchange, which defines token exchange for delegation and impersonation flows.

Why Combined Identity Context Matters

The security value of on-behalf-of authorization is that it prevents the service from becoming an accidental privilege amplifier. A workflow may begin with a legitimate user action, but if downstream systems only trust the service identity, they can lose the distinction between “what the user allowed” and “what the service could do.”

This pattern is especially important in cross-system orchestration, API mediation, and agentic or automated workflows where one actor performs work for another. The authorization decision needs enough context to preserve least privilege across the whole chain, not just at the point where the service presents itself to the resource.

That is why delegated access is usually paired with explicit token exchange or equivalent proof of original subject context, rather than reused service credentials alone. The policy problem is not only “is this service authenticated?” but also “is this service authorised to act for this user for this specific request?”

NHIMG’s OAuth Token Exchange and Delegation Guide is the clearest internal companion for the token-exchange mechanics behind this pattern.

Common Failure Modes in Delegated Workflows

On-behalf-of authorization fails when implementers collapse two actors into one and trust the service alone. That can lead to overbroad access, confused deputy behaviour, or downstream actions that were never meant to be available to the original user.

A related failure is scope drift, where a request starts as a narrow user action but later stages reuse a token or assertion that is broader than the original intent. Another common issue is weak audience control, where a token meant for one resource or one step in the chain is accepted more widely than it should be.

The control objective is to keep the original user context visible and enforceable at each decision point. Without that, delegated systems tend to accumulate implicit trust, and the resulting authorization path becomes harder to reason about, audit, and contain.

For broader authorization design, Authorisation Models Guide helps place on-behalf-of decisions alongside RBAC, ABAC, ReBAC, and policy-based access control.

Where This Pattern Is Used

On-behalf-of authorization appears wherever one component must act for a human or another principal without taking over full authority. That includes gateway-mediated APIs, service-to-service calls, workflow engines, assistant-style systems, and multi-step enterprise integrations that must preserve user intent across a chain of execution.

The pattern also maps well to environments that already use externalized authorization, because the policy engine can evaluate the original subject, the calling service, and the requested action together. That is often the difference between a delegation model that is merely convenient and one that is actually controlled.

In AI-heavy environments, the same principle applies when an automated system performs a user-requested action but should remain bounded by the user’s scope and approval. NHIMG’s AI Agent Authorisation Guide explains how to keep delegated action task-scoped and policy-driven.

Risk and Threat Considerations

Delegated workflows create a clear security exposure when the service identity is trusted more than the user intent. If the combined identity context is not enforced, a compromised service, an overly broad token, or a confused deputy path can turn legitimate delegation into unauthorized action.

Failure mechanism: The system evaluates only the calling service, or it accepts a delegated token without preserving the original user’s constraints, so downstream access expands beyond the intended scope.

Impact: Attackers or misconfigured services can perform actions the user never approved, creating privilege escalation, data exposure, and difficult-to-audit lateral access through trusted workflows.

Practitioner Guidance

Why practitioners should care: Treat on-behalf-of authorization as a policy design problem, not just a token-handling implementation detail. The key operational question is whether every resource decision can still prove who initiated the request and what authority was delegated.

Practitioner note: Use the same scrutiny you would apply to any least-privilege boundary, because delegated access can be safe only when the original subject remains visible to policy enforcement and auditing.

Related resources from NHI Mgmt Group

• Who should own authorization when an AI agent queries internal data on behalf of a user?
• How should security teams implement delegated authorization for on-behalf-of access in applications and identity flows?
• Why do LLM agents create new authorization risk when they can perform internal actions on behalf of users?
• What are MCP Authorization Extensions and how do they help organizations?