Edit

Share via

About authentication, authorization, and security policies

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

Azure DevOps uses a combination of security concepts to ensure that only authorized users can access its features, functions, and data. Access gets determined by two key processes: authentication, which verifies a user's credentials, and authorization, which grants permissions based on account entitlements. Together, these processes control what each user can do within Azure DevOps.

This article expands on Get started with permissions, access, and security groups and helps administrators understand the different account types, authentication and authorization methods, and security policies available to protect Azure DevOps environments.

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
  • Microfost Entra token
  • Personal access token
  • 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 supports software development from planning to deployment. Each platform uses 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 projects are safe, available, secure, and private, see the Azure DevOps 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 non-Microsoft 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 non-Microsoft 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 non-Microsoft 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 non-Microsoft 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 a user's identity based on the credentials provided during sign-in to Azure DevOps. Azure DevOps integrates with several identity systems to manage authentication:

  • Microsoft Entra ID: Recommended for organizations managing a large group of users. Provides robust, cloud-based authentication and user management.
  • Microsoft account (MSA): Suitable for smaller user bases accessing Azure DevOps organizations. Supports cloud authentication.
  • Active Directory (AD): Recommended for on-premises deployments with many users, using your existing AD infrastructure.

Microsoft Entra ID and Microsoft accounts both support cloud authentication. For more information, see About accessing Azure DevOps with Microsoft Entra ID.

For on-premises environments, use Active Directory to efficiently manage user access. Learn more in Set up groups for use in on-premises deployments.

Authenticate programmatically

Access your Azure DevOps organization programmatically without repeatedly entering your username and password by choosing one of the available authentication methods. Use the following methods to automate workflows, integrate with REST APIs, or build custom applications:

  • Use OAuth to build applications that perform actions on behalf of users. Users must consent to the app. For new apps, use Microsoft Entra OAuth.
  • Use service principals or managed identities to automate workflows or build tools that regularly access organization resources. Issue Microsoft Entra tokens on behalf of the application itself.
  • Use Microsoft Entra ID for secure, cloud-based authentication and user management.
  • Use personal access tokens (PATs) for ad-hoc requests or early prototyping. Avoid PATs for long-term app development, as they're more susceptible to leaks and misuse.

Tip

Always store credentials securely and follow best practices for managing authentication methods.

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 determines whether an authenticated identity has the required permissions to access a specific service, feature, function, object, or method in Azure DevOps. Authorization checks always occur after successful authentication—if authentication fails, authorization is never evaluated. Even after authentication, users or groups might be denied access to certain actions if they lack the necessary permissions.

Azure DevOps manages authorization through permissions assigned directly to users or inherited through security groups or roles. Access levels and feature flags can further control access to specific features. To learn more about these authorization methods, see Get started with permissions, access, and security groups.

Security namespaces and permissions

Security namespaces define user access levels for specific actions on Azure DevOps resources.

  • Each resource family, for example, work items or Git repositories, has its own unique namespace.
  • Within each namespace, there can be multiple access control lists (ACLs).
    • Each ACL contains a token, an inherit flag, and one or more access control entries (ACEs).
    • Each ACE specifies an identity descriptor, a bitmask for allowed permissions, and a bitmask for denied permissions.

For more information, see Security namespaces and permission reference.

Security policies

To secure your organization and code, organization-level (Project Collection Administrator) or tenant-level (Azure DevOps Administrator) admins can enable or disable various security policies, depending on the policy scope. Key policies to consider include:

If your organization is connected to Microsoft Entra ID, you have access to the following other security features:

Review and configure these policies to strengthen your organization's security posture and ensure compliance with your data privacy and access requirements.

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 limit access for specific users—such as Stakeholders, Microsoft Entra guest users, or members of a particular security group—enable the Limit user visibility and collaboration to specific projects preview feature for your organization. When this feature is enabled, any user or group added to the Project-Scoped Users group is restricted in the following ways:

  • Access is limited to the Overview and Projects pages within Organization settings.
  • Users can only connect to and view projects they're explicitly added to.
  • Users can only select user and group identities that are explicitly added to the same project.

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