Verify that the middle-tier app is registered as a valid resource client, the downstream permissions are consented, the assertion is an access token rather than an ID token, and offline access is included when refresh is needed. If any of those pieces are missing, the exchange may fail or behave inconsistently across tenants.
What Entra OBO depends on before Graph access works
On-behalf-of flow is not just a token exchange, it is a delegated access chain. The middle tier must be allowed to act as a resource client, and Graph must recognise the downstream permission path for the requested scope. If the app registration, consent state, or token type is wrong, the flow can fail even when the user is authenticated and the API call looks otherwise valid.
Teams should treat the app registration and consent model as the first checkpoint, not an afterthought. The exchange only works when the middle tier is configured to receive and redeem the user assertion for the downstream API, which is why configuration drift between environments often shows up as inconsistent tenant behaviour.
For the token itself, the exchange has to start from the right credential shape. An access token carries the delegated authorization the downstream service can use, while an ID token is for identity claims and is not a substitute for API delegation. If refresh is part of the design, offline access also has to be present so the app can keep the delegated session alive when the original interaction is no longer active.
Why OBO breaks in practice
The most common failure mode is mismatched assumptions across the three parties involved: the front end, the middle tier, and Graph. One side may be configured for delegated API access, while another is sending the wrong token type or lacks consent for the scope it is trying to request. That mismatch often appears only after deployment, because local testing can succeed with cached consent or a permissive tenant and then fail elsewhere.
Another practical issue is tenant variability. Consent, app registration, and permission grants can differ across tenants, especially when the same code path is deployed into environments with different admin consent history. That creates a class of failures that are not really runtime bugs, but configuration and governance gaps.
When the exchange fails, the fix is usually not in the Graph call itself. The right response is to verify the resource app registration, confirm the delegated permissions are consented in the target tenant, and validate that the incoming assertion is an access token intended for OBO. For token refresh scenarios, confirm the app has the delegated access required to continue the session rather than depending on a one-time interaction.
Risk and Threat Considerations
OBO failures matter because they can create both availability problems and authorization drift. If the middle tier accepts the wrong assertion type or relies on inconsistent consent, the application may fall back to brittle retries, hidden failures, or overbroad reauthentication patterns that are hard to diagnose. The same weaknesses can also expose gaps in how delegated access is bounded and audited.
Failure mechanism: The middle tier redeems an assertion that was not issued for delegated API access, or it tries to request Graph permissions that were never consented in that tenant. The token exchange then fails, or succeeds only in one environment where consent state happens to be different.
Impact: Users see inconsistent access to Graph data, refresh-dependent workflows break, and troubleshooting becomes difficult because the failure is rooted in identity and consent state rather than application logic. In delegated access paths, that also increases the chance of deploying a configuration that works in test but is unreliable or insecure in production.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | User-authenticated delegated access depends on valid token issuance and acceptance. |
| IA-5 — Authenticator Management | OBO depends on correct token handling, including access token use and refresh conditions. | |
| AC-6 — Least Privilege | Downstream Graph permissions should be scoped only to the delegated access actually needed. | |
| Recommendation — Validate the delegated authentication path before trusting downstream API access. Manage token lifecycle and refresh conditions so delegated access remains reliable. Restrict delegated Graph permissions to the minimum required scope. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The issue is governed access to Graph through delegated application control. |
| A.5.16 — Identity management | The flow depends on correctly registered clients and tenant-specific consent state. | |
| Recommendation — Define and enforce access rules for delegated application access. Verify identity registration and tenant consent before enabling delegated access. | ||
| OWASP ASVS | V10 — OAuth and OIDC | OBO is an OAuth delegated authorization pattern and hinges on token type and consent. |
| Recommendation — Test OAuth token flow assumptions, especially assertion type and consent. | ||
Practitioner Guidance
What to verify: Confirm the middle tier is the intended resource client, the downstream Graph scopes are explicitly consented, and the incoming assertion is an access token, not an ID token. If refresh is part of the use case, verify offline access is actually present in the delegated path.
Decision rule: If the flow works only in one tenant or only after an interactive sign-in, treat that as a configuration signal, not proof that OBO is correct. The cleanest diagnostic is to test the same app registration and scope set in the exact tenant where production traffic will run.
Practitioner takeaway: OBO succeeds only when the app registration, consent, and token type all line up for delegated API access; if any one of those is off, the flow will usually fail in ways that look intermittent rather than obviously broken.
Related resources from NHI Mgmt Group
- What should teams check before relying on MongoDB access controls in production?
- What should security teams check before relying on agentless compliance reporting?
- What should security teams check before extending access controls to autonomous systems?
- What should IAM and NHI teams check before relying on metadata-service credentials?