Azure DevOps REST API - Headless Authentication

1
votes

We will be building a couple of non-interactive scripts and console applications which will be invoking the Azure DevOps REST API to do various tasks. These apps and scripts will be executed via a job scheduler. What authentication scheme would be the correct one to use for this scenario? It seems like a PAT would work, however, I really don't want the jobs to be tied to a specific user identity and Azure DevOps does not support service principles. Is the correct approach to establish a "fake" Azure Active Directory user and use that user as the owner of the PATs? Is there something else that I am missing here?

Looking at the Authentication Guide, it seems like all of the mechanisms referenced result in some form of interactivity.

Also, we have Conditional Access Policies being enforced in our Azure DevOps organization. One of those policies is the requirement for MFA. If we use a PAT, how will that work? According to this link, it sounds like access may be blocked.

1
azureazure-devops
Yes, it's common to have an AAD "service account" and use either a PAT or OAuth with that account. PATs aren't subject to MFA. – Daniel Mann

1 Answers

1
votes

Personal access tokens (PATs) are used for personal authentication. They are alternate passwords that you can use to authenticate into Azure DevOps.

Really don't want the jobs to be tied to a specific user identity and Azure DevOps does not support service principles.

Yes, as you have pointed out. It doesn’t support to create a PAT token with a service account in Azure DevOps Service.

That would be ok to use the public fake MFA account to login Azure DevOps Service. And then use that account to generate PAT token. When request API, others simply use that generated PAT token to authenticate.

With CAP enabled the doc is clear. For Web flows, CAP is honored 100%. That means in most of the situations, Rest API will not be affected.

The limitation is third-party client flow. Some actually due to configuration of third-party. There's nothing we can do in Azure DevOps. You have to follow the policy mentioned in that link. If users do not meet IP range, it will be blocked.