Choosing the right authentication mechanism

Last Update: 7/14/2017

When writing an application which interfaces with VSTS, you will have to authenticate to gain acess to resources like REST APIs. We understand that VSTS offers many different ways to authenticate your application. This topic provides guidance to help you choose the right authentication for your application. The following table outlines the recommended authentication mechanism for different application types. We have provided 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 VSTS REST APIs Console application enumerating projects in an account Active Directory authentication library (ADAL) sample
Interactive client-side (Client library) Client application, that allows user interaction, calling VSTS 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 work items for a user ADAL sample (coming soon)
Non-interactive client-side Headless text only client side application Console application enumerating projects in an account Device Profile sample
Interactive web GUI based web application Custom Web dashboard displaying build summaries OAuth sample
VSTS Extension Visual Studio Team Services extension Agile Cards VSS Web Extension SDK sample walkthrough

Q&A

Q: Can I use ADAL if I log into my VSTS account with a Microsoft account (MSA)?

A: Yes, you do not need an Azure Active Directory (AAD) account to use ADAL.

Q: Is this guidence only for VSTS or is this also relevant for on-prem TFS users?

A: This guidence is mainly for VSTS users. Client Libraries are a series of packages built specifically for extending TFS functionality. For on-prem users, we recommend using the Client Libraries, Windows Auth, or Personal Access Tokens (PATs) to authenticate on behalf of a user.

Q: What if I want my application to authenticate with both TFS and Team Services?

A: The best practice is to have different authentication paths for TFS and Team Services. You can use the requestContext to find out which you’re hitting and then use the best mechanism for each. Alternatively, if you want a unified solution, PATs will work for both.