Choose the right authentication mechanism
TFS 2018
For applications that interface with Azure DevOps Services, you must authenticate to gain access to resources like REST APIs. This article provides guidance to help you choose the right authentication mechanism for your application.
The following table outlines the recommended authentication mechanism for various application types. See the following basic descriptions, examples, and code samples to get you started.
| Type of application | Description | Example | Authentication mechanism | Code samples |
|---|---|---|---|---|
| Interactive client-side (REST) | Client application that allows user interaction calling Azure DevOps Services REST APIs | Console application enumerating projects in an organization | Microsoft Authentication Library (MSAL) | sample |
| Interactive client-side (Client library) | Client application that allows user interaction calling Azure DevOps Services Client libraries | Console application enumerating bugs assigned to the current user | Client libraries | sample |
| Interactive JavaScript | GUI-based JavaScript application | AngularJS single page app displaying project information for a user | Microsoft Authentication Library for JavaScript (MSAL JS) | sample |
| Personal access token (PAT) | Bearer token to access your own resources | Use your PAT in place of your password. | PATs | |
| Non-interactive client-side | Headless text only client-side application | Console app displaying all bugs assigned to a user | Device Profile | sample |
| Interactive client-side app targeting Azure DevOps | Client application that allows user interaction authenticates Azure DevOps users | Console application allowing Azure DevOps users to see assigned bugs | Client Library (Interactive and Windows authentication) | sample |
| Interactive web | GUI-based web application that requires user consent | Custom Web dashboard displaying build summaries | Azure DevOps OAuth | sample |
| Service Principals or Managed Identities | Application with access to organization's Azure DevOps resources | Azure function to create work items | Service principals and managed identities | sample |
| Azure DevOps Server application | Azure DevOps Server app using the Client OM library | Azure DevOps Server extension displaying team bug dashboards | Client Libraries | sample |
| Azure DevOps Services Extension | Azure DevOps Services extension | Agile Cards | VSS Web Extension SDK | sample |
For a primer on security and identity concepts in Azure DevOps, see About security and identity. To learn more about how we store your credentials, see Credential storage for Azure DevOps.
Enabling IIS Basic Authentication invalidates using PATs for Azure DevOps Server
For more information, see Using IIS Basic Authentication with Azure DevOps on-premises.
Frequently asked questions (FAQs)
Q: Why can't one of my service accounts access the Azure DevOps REST API?
A: Your service account might not have "materialized." Since signing in isn't possible with a service account that doesn't have interactive signing in permissions, check out this work-around.
Q: I'm making an interactive client-side application. Should I use Azure DevOps Services Client Libraries or Azure DevOps Services REST APIs?
A: We recommend using Azure DevOps Services Client Libraries over REST APIs when accessing Azure DevOps Services resources. They're simpler and more easily maintained when version changes to our REST endpoints occur. If functionality is missing from the client libraries, MSAL is the best authentication mechanism to use 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 mainly for Azure DevOps Services users. Client Libraries are a series of packages built specifically for extending Azure DevOps Server functionality. For on-premises users, we recommend using the Client Libraries, Windows Auth, or Personal Access Tokens (PATs) to authenticate for a user.
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 different authentication paths for Azure DevOps Server and Azure DevOps Services. You can use the requestContext to find out which you're hitting and then use the best mechanism for each. Instead, if you want a unified solution, PATs works for both.