Building for Azure DevOps with Microsoft Entra OAuth Apps

Important

When creating a new OAuth 2.0 app, start here with Microsoft Entra OAuth apps, as Azure DevOps OAuth apps are planned for deprecation in 2026. Learn more in our blog post.

Microsoft Entra ID OAuth

Microsoft Entra ID is a separate Microsoft product with its own platform. On Microsoft Entra, you can register an application to access Azure tenants and define permissions needed from Azure resources, of which Azure DevOps is considered one.

Microsoft Entra apps and Azure DevOps apps are separate entities with no knowledge of each other. The means to authenticate your application differs from Microsoft Entra OAuth to Azure DevOps OAuth. For one thing, Microsoft Entra ID OAuth apps are issued Microsoft Entra tokens, not Azure DevOps access tokens. These tokens have a standard one-hour duration before expiration.

We recommend reading the Microsoft Entra documentation thoroughly to understand the new functionality available via Microsoft Entra and the different expectations of you during setup.

Why choose Microsoft Entra?

As a leading identity and access management (IAM) provider, Microsoft Entra ID is focused on the needs of companies that need to manage team members and safeguard company resources. Microsoft Entra ID offers many features -- application development and management is one of them. The Microsoft Entra application model offers a few advantages over the Azure DevOps OAuth app model that make them more appealing to app developers.

1. Broader reach inside and outside of Microsoft

By building an app on Microsoft Entra, you have a broader reach through the rest of the Microsoft ecosystem. One Microsoft Entra app can be used to access multiple Microsoft products, making app credential management far simpler. Teams offering SaaS products may consider creating a preintegrated application that appears alongside other popular apps in the Microsoft Entra app gallery.

2. Greater admin visibility, consent, and management

Trusted tenant admins can manage which apps access company resources, who in the organization can use the app, and how consent can be obtained. Azure DevOps OAuth doesn’t know knowledge of tenants or their admins, relying exclusively on users to authorize access to potentially sensitive data. Users that previously authorized access to a long-forgotten app are leaving the door open for later potential infiltration. Admin oversight provides an extra set of eyes with appropriate review processes and helpful cleanup of unused or unauthorized apps.

3. Tighter conditional access controls

Conditional access policies make it a breeze to set up the appropriate access controls on which users can and can't access your organization through a Microsoft Entra app. Azure DevOps OAuth app sits outside of the Microsoft Entra ecosystem and doesn’t adhere to all conditional access policies.

4. Self-serve app configuration

Changing app scopes and app ownership on a Microsoft Entra app is a relative breeze compared to Azure DevOps OAuth apps. App developers reach out to our customer support team to make changes on Azure DevOps OAuth apps, but in Microsoft Entra the power to change scopes is returned to the developer. App ownership can even be shared between multiple users and not restricted to a single user which may pose a problem if said user leaves the company in the future.

5. Sign-in logs available

Microsoft Entra logs all “sign-ins" into an Azure tenant, which includes your internal apps and resources. This additional information can offer some more insight into who is using your apps that aren't available through our auditing.

Helpful resources

Building on a new platform can be overwhelming. We provide some helpful links we think might be useful to the OAuth app development process on Microsoft Entra. For developers switching over from Azure DevOps OAuth to Microsoft Entra OAuth, we provide helpful tips to consider during your migration effort.

Good resources for developers

• Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow
• Understanding delegated access
• Quickstart: Register an application with the Microsoft identity platform
• Add permissions to access Microsoft Graph: Useful to learn how to add delegated permissions from an Azure resource. Instead of Microsoft Graph, select Azure DevOps from the list of resources instead.
• Scopes and permissions in the Microsoft identity platform: Read up on the .default scope. See the scopes available for Azure DevOps in our list of scopes.
• Requesting permissions through consent
• Authentication libraries and code samples
• Manage personal access tokens via API: Using the PAT lifecycle management APIs requires Microsoft Entra tokens and our docs and the associated sample app might be a helpful example for setting up a Microsoft Entra app to use Azure DevOps REST APIs.
• Support and help options for developers

Good resources for admins

• What is application management in Microsoft Entra ID?
• Quickstart: Add an enterprise application
• Consent experience for applications in Microsoft Entra ID

Building & migrating tips

Note

Microsoft Entra OAuth apps doesn't natively support MSA users for Azure DevOps REST APIs. If you are building an app that must cater to MSA users or supports both Microsoft Entra and MSA users, Azure DevOps OAuth apps remains your best option. We are currently working on native support for MSA users through Microsoft Entra OAuth.

• Good-to-know Azure DevOps IDs:
  • Microsoft Entra resource identifier: 499b84ac-1321-427f-aa17-267ca6975798
  • Resource Uri: https://app.vssps.visualstudio.com
  • Use the .default scope when requesting a token with all scopes that the app is permissioned for.
• When migrating an existing app, you may be using Azure DevOps user identifiers that don't exist in Microsoft Entra. Use the ReadIdentities API to resolve and match the different identities in use by each identity provider.

App-only flows on Microsoft Entra

Microsoft Entra OAuth is the recommended solution for building apps to access Azure DevOps services on-behalf-of a consenting user.

If you're looking to build an application to act on-behalf-of itself, then look into our documentation on service principal support. In these docs, we elaborate more on how to set up a service principal or managed identity that doesn't rely on user permissions to action on organization resources, instead relying solely on its own permissions. This authentication mechanism is the recommended authentication for building out automated tooling for teams.