A practical guide to PATs in Azure DevOps

What is a personal access token?

A PAT is a string of characters that authenticates access to Azure DevOps services. Think of it as a password that grants specific rights to a user account or service for a limited time. PATs are often used in automation scenarios or when interacting with the Azure DevOps REST APIs through scripts, CLI tools like curl or non-Microsoft CI/CD systems.

An example of using Azure DevOps PATs is when deploying a nonsensitive Azure Repo to a group of servers. Using a PAT enables the ability to narrowly scope what it can do -- such as read-only -- and make it last for six months. That way, pulling down the repository is simplified because no interaction is needed when it gets updated.

Unlike traditional usernames and passwords or complex service principals, PATs are scoped credentials. They are tied to a single user identity and can be limited in terms of permissions and lifetime, making them ideal for secure, temporary access.

Personal access tokens vs. API credentials

While PATs fall under the umbrella of API credentials, it's important to understand how they differ from other common authentication methods.

The following are key differences to keep in mind:

• PATs are user-scoped, not app-scoped. They act on behalf of a user.
• Service principals are for full automation or enterprise-level applications.
• API keys are for general-purpose authentication, but they lack granular controls and auditability.
• OAuth is the most dynamic, but it can be more complex to set up.

PATs offer a middle ground -- they're easier to use than service principals and more secure than generic API keys.

For quick integrations or when service principals are overkill, PATs are useful, especially when triggering builds, as well as pulling repos and artifacts. They aren't a substitute for full-fledged service principals or OAuth integrations, but they provide a balance between simplicity and security.

How to create a PAT in Azure DevOps

Creating a PAT in Azure DevOps is straightforward. Here's how to generate one and use it in a practical example.

Step 1. Navigate to the Azure DevOps user settings

Sign in to Azure DevOps, and in the top-right corner, click the person with the gear icon, which is the user settings button. Select Personal access tokens from the drop-down menu.

Step 2. Create a new token

Click + New Token. The wizard defaults to a custom-defined scope. Users can grant full access by clicking Full Access, but it is discouraged. Next, provide the following:

• Name. Describe what this token will do, such as build script access.
• Organization. Choose the appropriate Azure DevOps organization.
• Expiration. Select a valid expiration date or period, such as 30 days or custom.
• Scopes. Choose the level of access. For example, to fetch repo code, check Code (Read) or, to manage builds, check Build (Read & execute).

Step 3. Create the token

Once you click Create, the token displays only once. Copy it immediately, and store it -- preferably in a secrets manager or encrypted environment variable. You cannot retrieve a PAT again after this point. If lost, users need to regenerate it.

An example use case

Here's a simple real-world example of using a PAT to clone a repository using Git over HTTPS.

For command-line Git access, use the following:

git clone
https://dev.azure.com/YourOrgName/YourProjectName/_git/YourRepoName

When prompted for credentials, input the following:

• Username. The Azure DevOps username or email.
• Password. The PAT.

Alternatively, you can use the token directly in the URL:

git clone
https://<USERNAME>:<PAT_TOKEN>@dev.azure.com/YourOrgName/YourProjectName/_git/YourRepoName

Avoid hardcoding PATs into source code or shell scripts; this creates security vulnerabilities. Use secret injection mechanisms whenever possible to decrease the risk of token exposure.

How to revoke a PAT in Azure DevOps

Revoking a PAT is necessary if the following is true:

• The token is compromised.
• The user leaves the organization.
• The token is no longer necessary.

To revoke a token, do the following:

1. Go to User Settings > Personal Access Tokens.
2. Locate the token in the list.
3. Click the Revoke button next to the token.
4. Confirm the action.

The token becomes immediately invalid, and any script or system relying on it fails authentication. In the case of compromise, revoke the token immediately, and generate a new one with a different secret value.

Best practices for PAT management in Azure DevOps

PATs are a versatile way to authenticate with Azure DevOps, especially in automation and scripting scenarios -- but they are not foolproof. One key thing to remember is to treat tokens like passwords and rotate them regularly. Other key best practices include the following:

• Use the principle of least privilege. Only assign the minimum scopes necessary for a task. For instance, if a script only needs to fetch data, don't grant write or administrative permissions.
• Set short expiration times. Limit the lifespan of PATs. Default expiration ranges from 30 days to one year, but shorter lifespans are safer for automation.
• Store tokens securely. Use a secrets manager, like Azure Key Vault, HashiCorp Vault or AWS Secrets Manager. Never store PATs in plaintext files or hardcode them into applications.
• Monitor and audit usage. Azure DevOps does not provide granular PAT usage logs by default, but you can regularly review active tokens, implement IP restrictions and rotate tokens.
• Avoid sharing tokens. PATs tie to individual users. Sharing them undermines audit trails and accountability. Instead, assign separate tokens per user or task.
• Use environment variables. For local development and CI pipelines, pass tokens as environment variables, for example:
  

  export AZURE_DEVOPS_PAT="your_token_here"

  Then, use it in scripts like the following:
  

  curl -u ":$AZURE_DEVOPS_PAT"
  https://dev.azure.com/YourOrg/_apis/projects?api-version=7.0

Stuart Burns is an enterprise Linux administrator at a leading company that specializes in catastrophe and disaster modeling.