Clarification on Entra OAuth (OBO) Support for Azure DevOps – Multi-tenant

Question

We have implemented a web application where users authenticate using Microsoft Entra ID (OAuth 2.0). After successful login, we acquire an access token and use it to invoke Azure DevOps APIs (e.g., organization, repositories, branches, etc.).

To support secure downstream API access from our backend, we are using the On-Behalf-Of (OBO) flow to exchange the user token and obtain an access token for Azure DevOps resources.

To enable multi-tenant support, we have configured a multi-tenant app registration.

• The current implementation works fine for users within our primary tenant (e.g., @blackduck.com).
• To simulate external customer scenarios, we created a separate sandbox tenant and tested with users such as ******@sandbox.blackduck.com.

---

Question

Is testing with a separate sandbox tenant (e.g., sandbox.blackduck.com) considered a valid approach to simulate real customer environments (e.g., users from domains like @cisco.com)?

Specifically, does this setup accurately represent cross-tenant authentication behavior and access patterns that would be expected when real external customers use the application?

One More Question -
For our multi-tenant application, users from external tenants are prompted with a message indicating that admin consent is required for application access.

• Is this behavior a default Microsoft Entra ID policy, or can it be controlled/modified by the application publisher?
• If admin consent is required, can we provide a standard set of steps to customer tenant administrators so that they can grant consent once and unblock all users in their organization?

Answer 1

Hi @Gourav Jangra

Thank you for reaching out to Microsoft Q&A.

In your scenario, the behavior you are observing is expected for a multi-tenant Microsoft Entra ID application integrated with Azure DevOps using OAuth (OBO flow). Testing with a separate sandbox tenant is a valid and recommended approach because each tenant in Entra ID acts as an isolated identity boundary, similar to how real external customer tenants operate. This setup correctly simulates cross-tenant authentication, token issuance, and service principal creation. However, when users from external tenants attempt to access the application, they are prompted for admin consent because the application is requesting permissions that require administrator approval. This is not an issue with your implementation but rather a result of Microsoft Entra ID’s default security model, where consent behavior is governed by both the permissions requested by the application and policies configured in the external tenant. Many organizations restrict user consent and require an administrator to approve apps before users can access them.

Refer below points to resolve this issue or this is the workaround

Sandbox tenant testing is valid and recommended

A separate tenant behaves exactly like a real customer tenant for authentication and authorization scenarios.

It accurately simulates multi-tenant login, token issuance, and consent behavior.

This is aligned with Microsoft guidance to use a dedicated test tenant for development and validation.

Admin consent prompt is expected behavior

External users see “Admin approval required” because the application requests permissions that cannot be granted by end users.

Consent experience depends on tenant policies and permission scope, not just application configuration.

Provide admin consent flow to customers (One-time setup)

Share a standard admin consent URL so tenant admins can approve the application once:

https://login.microsoftonline.com/{tenant-id}/v2.0/adminconsent  
?client_id=<your-client-id>  
&redirect_uri=<your-redirect-uri>  

This uses the Microsoft Entra admin consent endpoint for tenant-wide approval.

Alternative: Portal-based admin approval

Admin can navigate to:

Entra ID → Enterprise Applications

Select your application

Go to Permissions → Click “Grant admin consent”

This grants access to all users in that tenant and removes further consent prompts.

Best practice to minimize friction

Request only least-privileged delegated permissions

Provide clear onboarding documentation for customer admins

Handle multi-tenant token validation properly (issuer, audience)

Answer 2

Using a separate sandbox tenant to test the multitenant OBO flow and Azure DevOps access is a valid and representative approach, as long as the app is configured as multitenant and the code uses the /common (or equivalent) authority and handles multiple issuers.

From the Microsoft Entra perspective, each tenant is an isolated identity and access management scope that behaves like a separate customer organization. A tenant contains its own users, groups, apps, and policies, and tenant admins control which apps are available and what access policies apply. This is the same model that will apply when real external customers (for example, users from @cisco.com) use the application.

Therefore, testing with a second tenant such as sandbox.blackduck.com accurately exercises:

• Cross-tenant sign-in to a multitenant app
• Consent behavior per tenant
• Token issuance and validation for different issuers
• OBO behavior when the user is from a different tenant than the app’s home tenant

As long as the sandbox tenant is configured with realistic policies (for example, admin consent requirements, conditional access, etc.), this setup is a good proxy for real customer tenants.

Regarding the admin consent prompt for external users:

1. This behavior is driven by Microsoft Entra ID policies and consent settings in the customer’s tenant, not by the application alone. In a multitenant app, users in any tenant can sign in after consenting to use their account with the application. Whether end users can self-consent or require admin consent depends on the target tenant’s configuration.
2. The application publisher cannot unilaterally bypass or disable admin consent requirements in other tenants. What can be controlled on the app side is:
   • Declared permissions (scopes/roles) so that only the necessary permissions are requested.
   • Use of .default and known client applications in OBO scenarios so that consent is combined appropriately for client and middle-tier APIs.
3. If admin consent is required in customer tenants, it is possible to provide a standard set of steps for their administrators, for example:
   • Sign in to the Microsoft Entra admin portal for their tenant.
   • Locate the multitenant application in Enterprise applications.
   • Review and grant admin consent for the requested permissions so that all users in their organization (or a defined subset, if they restrict the app) can access the app without each user needing individual admin approval.

This pattern—multitenant app, cross-tenant sign-in, and admin consent per tenant—is the expected and supported model for SaaS applications using Microsoft Entra ID and OBO flows.

---

References:

• Convert single-tenant app to multitenant on Microsoft Entra ID
• Multitenant organization capabilities in Microsoft Entra ID
• Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow
• Restrict a Microsoft Entra app to a set of users
• Use Azure DevOps OAuth 2.0