About security, authentication, and authorization
TFS 2017 | TFS 2015 | TFS 2013
Azure DevOps employs a number of security concepts to ensure only those who should have access to features, functions, and data have access. Accounts get access to Azure DevOps through authentication of their security credentials and authorization of their account entitlements to access a feature or function.
This article builds on the information provided in Get started with permissions, access, and security groups. Administrators benefit from understanding the account types, authentication methods, authorization methods, and policies used to secure Azure DevOps.
Account types
- Users
- Service accounts
- Service principals
- Job agents
Authentication
- User credentials
- Windows authentication
- Two-factor authentication (2FA)
- SSH key authentication
- Personal access tokens
- Oauth configuration
- Active Directory authentication library
Authorization
- Security group membership
- Role-based permissions
- Access levels
- Feature flags
- Security namespaces & permissions
Policies
- Git repository and branch policies
Important
Azure DevOps no longer supports Alternate Credentials authentication since the beginning of March 2, 2020. If you're still using Alternate Credentials, we strongly encourage you to switch to a more secure authentication method (for example, personal access tokens). Learn more.
Both our cloud service, Azure DevOps Services, and on-premises server, Azure DevOps Server, support software development projects, from planning through deployment. Azure DevOps uses Microsoft Azure's Platform as a Service infrastructure and many of Azure's services, including Azure SQL databases, to deliver a reliable, globally available service for your development projects.
Accounts
While the main types of accounts of interest are the user accounts that you add to your organization or project, Azure DevOps supports other types of accounts to perform various operations. These include the following account types.
- Service accounts: Internal Azure DevOps accounts used to support a specific service, such as Agent Pool Service, PipelinesSDK. For descriptions of service accounts, see Security groups, service accounts, and permissions.
- Service principals: Internal Azure DevOps accounts to support internal operations.
- Job agents: Internal accounts used to run specific jobs on a regular schedule.
- Third party accounts: Accounts that require access to support Web hooks, service connections, or other third-party applications.
The most effective means for managing accounts is by adding them to security groups.
Note
The organization owner and members of the Project Collection Administrators group are granted full access to most all features and functions.
Authentication
Authentication verifies an account identity based on the credentials provided when they sign into Azure DevOps. These systems integrate with and rely upon the security features provided by these additional systems:
- Azure Active Directory (Azure AD)
- Microsoft account (MSA)
- Active Directory (AD)
Azure AD and MSA support cloud authentication. We recommend Azure AD when you need to manage a large group of users. Otherwise, if you have a small user base accessing your organization in Azure DevOps, you can use Microsoft accounts. For additional information, see About accessing Azure DevOps with Azure Active Directory (Azure AD).
For on-premises deployments, AD is recommended when managing a large group of users. For additional information, see Set up groups for use in on-premises deployments.
Authentication methods, integrating with other services and apps
Other applications and services can integrate with services and resources in Azure DevOps. To access your account without asking for user credentials multiple times, apps can use the following authentication methods.
Personal access tokens to generate tokens for:
- Accessing specific resources or activities, like builds or work items
- Clients like Xcode and NuGet that require usernames and passwords as basic credentials and don't support Microsoft account and Azure Active Directory features like multi-factor authentication
- Accessing Azure DevOps REST APIs
OAuth to generate tokens for accessing REST APIs. The Accounts and Profiles APIs support only OAuth.
SSH authentication to generate encryption keys when you use Linux, macOS, or Windows running Git for Windows and can't use Git credential managers or personal access tokens for HTTPS authentication.
By default, your account or collection allows access for all authentication methods. You can limit access, but you must specifically restrict access for each method. When you deny access to an authentication method, no app can use that method to access your account. Any app that previously had access gets an authentication error and can't access your account.
To learn more about how we store your credentials, see Credential storage for Azure DevOps.
To learn more about how to choose the right authentication mechanism, see Guidance for authentication.
Authorization
Authorization verifies that the identity which is attempting to connect has the necessary permissions to access a service, feature, function, object, or method. Authorization always occurs after successful authentication. If a connection is not authenticated, it fails before any authorization checking is performed. If authentication of a connection succeeds, a specific action might still be disallowed because the user or group did not have authorization to perform that action.
Authorization depends on the permissions assigned to the account. Permissions are granted either directly to an account, or through membership in a security group or security role. Access levels and feature flags can also grant or restrict access to a feature. To learn more about these authorization methods, see Get started with permissions, access, and security groups.
Security namespaces and permissions
Security namespaces store data that determines the level of access that Azure DevOps accounts have to perform a specific action on a specific resource. Each family of resources, such as work items or Git repositories, is secured through a unique namespace. Each security namespace contains zero or more access control lists (ACLs). Each ACL contains a token, an inherit flag, and a set of zero or more access control entries (ACEs). Each ACE contains an identity descriptor, an allowed permissions bitmask, and a denied permissions bitmask.
To learn more, see Security namespaces and permission reference.
Security policies
To secure your code, you can set a number of Git repository and branch policies. To learn more, see the following articles.
- Configure repository settings and policies
- Configure branch policies
- Configure branch policy for an external service
- Use Azure Functions to create custom branch policies
Azure Repos and Azure Pipelines security
Since repositories and build and release pipelines pose unique security challenges, additional features beyond those discussed in this article are employed. To learn more, see the following articles.
- Securing Azure Pipelines
- Plan how to secure your YAML pipelines
- Repository protection
- Pipeline resources
- Recommendations to securely structure projects in your pipeline
- Security through templates
- How to securely use variables and parameters in your pipeline
- Recommendations to secure shared infrastructure in Azure Pipelines
- Other security considerations