We are proud to announce that Service Principals and Managed Identities can now be used to authenticate with Azure DevOps. For those who have not heard of them before, these Azure Active Directory identities enable teams to gain access to your Azure DevOps organizations acting as their own application, not as a human user or service account.
Why is this important?
Service principals and managed identities provide an exciting new alternative to personal access tokens (PATs), one of our most widely used authentication methods that is tied to the user that created the token. Teams have traditionally relied on PATs to power applications, services, and automation tools to access organizational resources. However, using an authentication method tied to a single person also means relying on a single point-of-failure. When a user leaves the company, the PAT driving the team application will become inaccessible to all other team members.
Additionally, PATs are bearer tokens, which can be leaked easily and fall into the wrong hands. (Remember to always secure your secrets in a key management solution, like Azure Key Vault!) This leaked PAT can then be used to wreak havoc for the remaining duration of the PAT’s lifetime, or until revoked.
There is a time and place for when PATs make sense; but for many applications out there, we welcome you to explore service principals and managed identities instead.
What are service principals and managed identities?
This feature is available to Azure AD-backed organizations only.
Let’s say your team wants to create an automation tool that adds a work item for every email that comes through a team inbox. Consider using an Azure AD application, which you can then use to generate tokens for calling Azure DevOps REST APIs in your code. The Azure AD application you create has an identity called the service principal, which keeps track of what permissions the application has across all Azure resources. These service principals also serve as the application’s identity in Azure DevOps, where we track what permissions it has in each organization, project, team, etc.
Managed identities take it one step further. These identities also allow you to connect to resources that support Azure AD authentication, but they eliminate the need for developers to manage any credentials. All secrets, certificates, keys, are maintained and rotated for you, meaning you don’t need to rely on Azure Key Vault to house critical keys or secrets. Managed identities are only available on top of Azure VMs and are restricted to a single Azure AD tenant.
With service principals and managed identities comes all the additional security and management benefits available through Azure Active Directory today. Now, with support in Azure DevOps, you can use the same authentication available to other Azure resources.
How do I get started?
With this public preview launch, you can begin using these features today!
Everything you need to get started is in our docs: Use Azure AD service principals & managed identities.
We’re glad to finally get this highly requested feature into your hands. As we continue to improve on this feature, we welcome any questions or feedback in the Comments below or on our Developer Community. Happy coding!
We could not authenticate in Azure DevOps with an Azure VM Scale Set due to the below:
The only service connection currently supported is an Azure Resource Manager (ARM) service connection based on a service principal key. ARM service connections based on a certificate credential or a Managed Identity will fail. When you attempt to list the existing scale sets in your subscription, you'll see an error like this:
Invalid Service Endpoint with Id and...
Can we disable the usage of PATs for users?
I’m very happy to see this feature. If I want to use the service principal for reading and writing code then it will need to have a
Basiclicense. We are using the MS cloud-hosted Azure DevOps. Do we get billed for licenses assigned to service principals, just like we would for a regular user? Thanks!Never mind, I found the answer on the docs page you linked to.
A service principal counts as a license for each organization it's added to, even if multi-organization billing is selected.
This is really too bad, and feels like a money grab for companies that want to be more secure by using Service Principals 😔, unless the Azure DevOps interactions they need to perform can get by with the free license.
Unless we plan...
Hi,
This is very good news, authenticating with a service principal is much better than with a PAT.
I have been trying to get the authentication to work using a service principal and Azure Data Factory, but I cannot get it to work.
Is invoking rest calls using Azure Data Factory in combination with Service Principal authentication supported yet?
In the docs there are examples using C# and Azure Functions, but it would be very nice to authenticate...
Such a nice quality of life feature specially for automation tools
I am working on removing PAT token dependency and planning to move to managed identity, currently we are using PAT token to authenticate our application with Azure DevOps resources.
I read the document Use Azure Active Directory service principals & managed identities - Azure DevOps | Microsoft Learn and I am trying to add managed identity to our Azure DevOps organizations(Microsoft) to grant access to our organization resources.
Since I am not having Project Admin access(Project...
You need to reach out to your organization administrator for this.
“>alert(1)
alert(1)”>”>alert(1)
“>alert(1)