About security, authentication, and authorization

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Azure DevOps employs many security concepts to ensure only those users 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
  • Organization owner
  • Service accounts
  • Service principals or managed identities
  • 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 access control
  • Access levels
  • Feature flags
  • Security namespaces & permissions

Policies

  • Privacy policy URL
  • Application connection and security policies
  • User policies
  • Git repository and branch policies


Account types

  • Users
  • Service accounts
  • Service principals or managed identities
  • 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.

For more information about the steps Microsoft takes to keep your projects in Azure DevOps Services safe, available, secure, and private, see this white paper, Azure DevOps Services Data Protection Overview.

Accounts

While the main types of accounts of interest are the human 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.

  • Organization owner: The creator of an Azure DevOps Services organization or assigned owner. To learn who is the organization owner for your organization, see Look up the organization owner.
  • 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 or managed identities: Microsoft Entra applications or managed identities that have been added to your organization to perform actions on behalf of a third-party application. Some service principals refer to 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.

Throughout these docs, users can refer to all identities that have been added to the Users Hub, which can include human users and service principals.

  • 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 or managed identities: Microsoft Entra applications or managed identities that have been added to your organization to perform actions on behalf of a third-party application. Some service principals refer to 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 other systems:

  • Microsoft Entra ID
  • Microsoft account (MSA)
  • Active Directory (AD)

Microsoft Entra ID and MSA support cloud authentication. We recommend Microsoft Entra ID 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 more information, see About accessing Azure DevOps with Microsoft Entra ID.

For on-premises deployments, AD is recommended when managing a large group of users. For more 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 on behalf of yourself 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 Microsoft Entra features like multi-factor authentication
    • Accessing Azure DevOps REST APIs
  • Azure DevOps OAuth to generate tokens on behalf of users for accessing REST APIs. The Accounts and Profiles APIs support only OAuth.

  • SSH authentication to generate encryption keys for yourself 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.

  • Service principals or managed identities to generate Microsoft Entra tokens on behalf of an application or service, that typically automates some workflow that needs to access Azure DevOps resources. Most actions traditionally done by a service account and a PAT can be done using a service principal or managed identity.

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.

For more information about how we store your credentials, see Credential storage for Azure DevOps.

For more information about how to choose the right authentication mechanism, see Guidance for authentication.

Authorization

Authorization verifies that the identity that 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 isn't 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 didn't 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. For more information 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.

For more information, see Security namespaces and permission reference.

Security policies

To secure your organization and code, you can set many policies. Specifically, you can enable or disable the following policies:

General

Application connection and security policies

Use the Microsoft Entra tenant policy to restrict creating new organizations to desired users only. This policy is turned off by default and only valid when the organization is connected to Microsoft Entra ID. Check restrict organization creation for more details.

The following policies determine the access you want to give users and applications to your organizations:

User policies

  • External guest access (Only valid when the organization is connected to Microsoft Entra ID.): When enabled, invitations can be sent to email accounts of users who aren't members of the tenant Microsoft Entra ID through the Users page. For more information, see Add external users to your organization.
  • Allow team and project administrators to invite new users: Only valid when the organization is connected to Microsoft Entra ID. When enabled, team and project administrators can add users through the Users page. For more information, see Restrict new user invitations from Project and Team Administrators.
  • Request access: Only valid when the organization is connected to Microsoft Entra ID. When enabled, users can request access to a resource. A request results in an email notification to the administrators asking for review and access, as needed. For more information, see Add external users to your organization.
  • Invite GitHub users: Only valid when the organization isn't connected to Microsoft Entra ID. When enabled, administrators can add users based on their GitHub user accounts from the Users page. For more information, see Authenticating & inviting GitHub users FAQs.

Project-Scoped Users group

By default, users added to an organization can view all organization and project information and settings. This includes viewing list of users, list of projects, billing details, usage data, and more that is accessed through Organization Settings.

Important

  • The limited visibility features described in this section apply only to interactions through the web portal. With the REST APIs or azure devops CLI commands, project members can access the restricted data.
  • Guest users who are members in the limited group with default access in Microsoft Entra ID, can't search for users with the people picker. When the preview feature's turned off for the organization, or when guest users aren't members of the limited group, guest users can search all Microsoft Entra users, as expected.

To restrict select users, such as Stakeholders, Microsoft Entra guest users, or members of a particular security group, you can enable the Limit user visibility and collaboration to specific projects preview feature for the organization. Once that is enabled, any user or group added to the Project-Scoped Users group, are restricted in the following ways:

  • Can only access the Overview and Projects pages of Organization Settings.
  • Can only connect and view those projects to which they've been added to explicitly (see Add users to a project or team.
  • Can only select user and group identities that have been added explicitly to the project they're connected to.

For more information, see Manage your organization, Limit user visibility for projects and more and Manage preview features.

Warning

When the Limit user visibility and collaboration to specific projects preview feature is enabled for the organization, project-scoped users are unable to search for users who were added to the organization through Microsoft Entra group membership, rather than through an explicit user invitation. This is an unexpected behavior and a resolution is being worked on. To self-resolve this issue, disable the Limit user visibility and collaboration to specific projects preview feature for the organization.

Git repository and branch policies

To secure your code, you can set many Git repository and branch policies. For more information, see the following articles.

Azure Repos and Azure Pipelines security

Since repositories and build and release pipelines pose unique security challenges, other features beyond the features discussed in this article are employed. For more information, see the following articles.

Next steps