dizen
dizen

Reputation: 11

Most secure way to authenticate in Azure DevOps Repo from non-interactive script

I need to work with Azure DevOps Repository (clone, push, pull) from non-interactive script. I've found only the solution to authenticate using PAT (https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=Windows):

$MyPat = 'yourPAT'
$B64Pat = [Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes("`:$MyPat"))
git -c http.extraHeader="Authorization: Basic $B64Pat" clone https://dev.azure.com/yourOrgName/yourProjectName/_git/yourRepoName

But I don't want to use Basic authentication. Are there more secure solutions?

Expect to authenticate using OAuth by service principal using client credentials flow to generate access token and use it in http.extraHeader

Upvotes: 1

Views: 848

Answers (1)

bk2204
bk2204

Reputation: 76754

In general, Git doesn't offer many complicated ways to authenticate. For example, using some technique to sign a request is difficult because the body is streamed and not known beforehand, so it can't be signed.

Git, through libcurl, knows how to do Basic, Digest, NTLM, and Kerberos authentication. Digest and NTLM are both problematic because they most often use broken cryptography and require credentials to be stored in an insecure way. Kerberos is secure, but it requires that you're part of a Kerberos realm and it's tricky to use in a non-interactive way.

That leaves Basic. Since you're using HTTPS, your data is protected from being read or tampered with, and so Basic is a secure approach. It is recommended to limit the scope of the personal access token as much as possible to limit the damage if it's exposed.

Note that you should prefer to avoid passing credentials via http.extraheader because that causes various things to break and isn't very secure because we assume anyone on the same machine can read all command-line arguments. Instead, expose the PAT through the environment and use the technique outlined in the Git FAQ to read it from there, which is more secure.

Upvotes: 2

Related Questions