Choosing the right authentication mechanism
Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - 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||Active Directory authentication library (ADAL)||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|
|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 Services and TFS||Client application, that allows user interaction, authenticates Azure DevOps Services and TFS users||Console application allowing Azure DevOps Services and TFS 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|
|TFS application||TFS app using the Client OM library||TFS extension displaying team bug dashboards||Client Libraries||sample|
|Azure DevOps Services Extension||Azure DevOps Services extension||Agile Cards||VSS Web Extension SDK||sample walkthrough|
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 TFS
Learn more about using IIS Basic Authentication with TFS 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, ADAL is the best authentication mechanism to use with our REST APIs.
Q: Can I use ADAL if I log into my organization with a Microsoft account (MSA)?
A: Yes, you can use ADAL to create client-side applications for an MSA backed account using ADAL with some limitations. Instead of configuring ADAL with a
Client ID or
Reply URL from Azure portal, MSA users can use the
Client ID: "872cd9fa-d31f-45e0-9eab-6e460a02d1f1" and
Reply URL: "urn:ietf:wg:oauth:2.0:oob" as replacement values to get a valid ADAL access token without needing an Azure Active Directory.
This approach only works for client side applications. For JS web apps, ADAL JS doesn't work without an Azure AD tenant.
Q: Is this guidance only for Azure DevOps Services or is it also relevant for on-premises TFS users?
A: This guidance is mainly for Azure DevOps Services users. Client Libraries are a series of packages built specifically for extending TFS 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 TFS and Azure DevOps Services?
A: The best practice is to have different authentication paths for TFS 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 will work for both.