Events
Apr 8, 3 PM - May 28, 7 AM
Sharpen your AI skills and enter the sweepstakes to win a free Certification exam
Register now!Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
For applications that interface with Azure DevOps Services, you must authenticate to gain access to resources through the Azure DevOps Services REST APIs. This article provides guidance to help you choose the right authentication mechanism for your application.
The following table outlines suggested authentication concepts to consider for different application scenarios. Refer to the accompanying descriptions, examples, and code samples to help get you started.
| Type of application | Description | Example | Authentication mechanism | Code samples |
|---|---|---|---|---|
| Interactive client-side app (REST) | Client application that allows user interaction and calls REST APIs directly | Console application enumerating projects in an organization | OAuth with Microsoft Authentication Library (MSAL) | sample |
| Interactive client-side app (client libraries) | Client application that allows user interaction and calls Azure DevOps Services client libraries | Console application enumerating bugs assigned to the current user | OAuth with client libraries | sample |
| Non-interactive client-side app | Headless text-only client-side application | Console app displaying all bugs assigned to a user | OAuth with Device Profile flow | sample |
| Personal access token (PAT) | Bearer token to access your own resources | Use your PAT in place of your password for ad-hoc REST calls. Not ideal for applications. | PATs | examples |
| Server app | Azure DevOps Server app using the Client OM library | Azure DevOps Server extension displaying team bug dashboards | Client Libraries | sample |
| Service principal or Managed identity | Application with its own identity | Azure function to create work items | Service principals and managed identities | sample |
| Web extension | Azure DevOps Services extension | Agile Cards extension | VSS Web Extension SDK | sample |
Tip
Entra-based authentication is our recommendation for developers looking to integrate with Azure DevOps Services, if you are interacting with Microsoft Entra accounts. The OAuth sample apps in this table use Microsoft Entra's identity platform for app development.
For authentication with Microsoft accounts (MSA) or Azure DevOps Server users, look into our client libraries or PATs.
Read up more in our blog on how we're reducing PAT usage across our platform.
Q: Should I use Azure DevOps Services Client Libraries or Azure DevOps Services REST APIs for my interactive client-side application?
A: We recommend using Azure DevOps Services Client Libraries over REST APIs for accessing Azure DevOps Services resources. They're simpler and easier to maintain when REST endpoint versions change. If the client libraries lack certain functionality, use MSAL for authentication with our REST APIs.
Q: Is this guidance only for Azure DevOps Services or is it also relevant for on-premises Azure DevOps Server users?
A: This guidance is primarily for Azure DevOps Services users. For Azure Devops Server users, we recommend using the Client Libraries, Windows Authentication, or Personal Access Tokens (PATs) for authentication.
Q: What if I want my application to authenticate with both Azure DevOps Server and Azure DevOps Services?
A: The best practice is to have separate authentication paths for Azure DevOps Server and Azure DevOps Services. You can use the requestContext to determine which service you're accessing and then apply the appropriate authentication mechanism. If you prefer a unified solution, PATs work for both.
A: Your service account might not have "materialized." Service accounts without interactive sign-in permissions can't sign in.