Choose the right authentication mechanism
TFS 2017 | TFS 2015 | TFS 2013
For applications that interface with Azure DevOps Services, you must authenticate to gain access to resources like REST APIs. We understand that Azure DevOps Services offers many different ways to authenticate your application. This article provides guidance to help you choose the right authentication for your application. The following table outlines the recommended authentication mechanism for different 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) | Easy alternative to regular OAuth tokens. | 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 | Custom Web dashboard displaying build summaries | OAuth | 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 walk through |
Note
The Azure DevOps API doesn't support non-interactive service access via service principals.
To learn more about how security and identity are managed, 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
Learn more about 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 may 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.