Edit

Share via

About authentication, authorization, and security policies

  • Article

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

Azure DevOps employs various security concepts to ensure that only authorized users can access features, functions, and data. Users gain access to Azure DevOps through the authentication of their security credentials and the authorization of their account entitlements. The combination of both determines the user's access to specific features or functions.

This article builds on the information provided in Get started with permissions, access, and security groups. Administrators can 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 doesn't support Alternate Credentials authentication. If you're still using Alternate Credentials, we strongly encourage you to switch to a more secure authentication method.

Both Azure DevOps Services (cloud) and Azure DevOps Server (on-premises) support software development from planning to deployment. Each platform leverages Microsoft Azure's Platform as a Service infrastructure and services, including Azure SQL databases, to provide a reliable, globally available service for your projects.

For more information about how Microsoft ensures your Azure DevOps Services projects are safe, available, secure, and private, see the Azure DevOps Services data protection overview.

Accounts

While human user accounts are the primary focus, Azure DevOps also supports various other account types for different operations:

  • Organization owner: The creator of an Azure DevOps Services organization or assigned owner. To find the owner for your organization, see Look up the organization owner.
  • Service accounts: Internal Azure DevOps organization 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 added to your organization to perform actions on behalf of a third-party application. Some service principals refer to internal Azure DevOps organization 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 our security-related articles, "users" refers to all identities added to the Users Hub, which can include human users and service principals.

  • Service accounts: Internal Azure DevOps organization 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 added to your organization to perform actions on behalf of a third-party application. Some service principals refer to internal Azure DevOps organization 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 way to manage 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 nearly all features and functions.

Authentication

Authentication verifies an account's identity based on the credentials provided during sign-in to Azure DevOps. These systems integrate with and rely on the security features of the following other systems:

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

Microsoft Entra ID and MSA support cloud authentication. We recommend using Microsoft Entra ID for managing a large group of users. For a small user base accessing your Azure DevOps organization, Microsoft accounts are sufficient. For more information, see About accessing Azure DevOps with Microsoft Entra ID.

For on-premises deployments, AD is recommended for managing a large group of users. For more information, see Set up groups for use in on-premises deployments.

Authentication

To access your account without repeatedly asking for your username and password, you may use any of the available authentication methods. This is helpful to access your account programmatically instead of through the website, or if you are an app developer building on top of Azure DevOps REST APIs. Some of the most popular authentication mechanisms include:

  • OAuth to build applications that perform actions on-behalf-of the app users. Users must provide consent to the app. Microsoft Entra OAuth is recommended for new apps.
  • Service principals can be used to build apps or tools that automate workflows that regularly access organization resources. Use this app identity to issue Microsoft Entra tokens on-behalf-of the application itself.
  • Personal access tokens (PATs) can be used for ad-hoc requests or early prototyping. It is not recommended for long-term app development as they can be easily leaked and used maliciously when leaked. Some clients are still reliant on PATs and have now

Tip

Remember to always safely store credentials!

By default, your organization allows access for all authentication methods. Organization admins can restrict access to these authentication methods by disabling security policies. Tenant admins can further reduce PAT risk by restricting the ways in which they can be created.

Authorization

Authorization verifies that the identity 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 checks are performed. Even if authentication succeeds, a specific action might still be disallowed if the user or group lacks authorization.

Authorization depends on the permissions assigned to the user, either directly or through membership in a security group or security role. Access levels and feature flags can also manage access to specific features. For more information about these authorization methods, see Get started with permissions, access, and security groups.

Security namespaces and permissions

Security namespaces determine user access levels for specific actions on resources.

  • Each resource family, such as work items or Git repositories, has a unique namespace.
  • Each namespace contains zero or more access control lists (ACLs).
    • Each ACL includes a token, an inherit flag, and access control entries (ACEs).
    • Each ACE has 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 enable or disable various policies if you are an organization-level (Project Collection Administrator or tenant-level (Azure DevOps Administrator) admin, depending on the policy. Some notable ones to consider include:

If the organization is connected to Microsoft Entra ID, even more security features are available to your organization.

Project-Scoped Users group

By default, users added to an organization can view all organization and project information and settings, including user lists, project lists, billing details, usage data, and more.

To restrict certain users, such as Stakeholders, Microsoft Entra guest users, or members of a specific security group, you can enable the Limit user visibility and collaboration to specific projects preview feature for the organization. Once 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 that they are added to explicitly.
  • Can only select user and group identities 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

Consider the following limitations when using this preview feature:

  • 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.
  • Users in the limited group can only select users who are explicitly added to Azure DevOps and not users who have access through Microsoft Entra group membership.
  • 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.

Git repository and branch policies

To secure your code, you can set various 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

Permissions and groups reference