DigitalOcean Personal Access Tokens (PATs) are the modern way to interact with the DigitalOcean API, replacing SSH keys for programmatic access.
Let’s see a PAT in action. Imagine you want to list all your Droplets. Instead of using doctl with an API key file, you can use curl with a PAT directly:
curl -X GET \
"https://api.digitalocean.com/v2/droplets" \
-H "Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN"
This curl command makes a GET request to the DigitalOcean API’s /v2/droplets endpoint. The Authorization header is where the magic happens: Bearer YOUR_PERSONAL_ACCESS_TOKEN tells DigitalOcean exactly who is making the request and that they have permission to access your Droplet information.
What Problem Do PATs Solve?
Before PATs, interacting with the DigitalOcean API programmatically usually meant relying on SSH keys. This worked, but it had a few drawbacks:
- Limited Scope: SSH keys are primarily designed for secure shell access. Using them for API operations felt like a workaround.
- Management Overhead: Managing SSH keys for API access could become cumbersome, especially in automated environments. You’d need to ensure keys were securely stored and rotated.
- Security Concerns: If an SSH key used for API access was compromised, it could potentially grant broad access.
PATs offer a more granular and purpose-built solution. They are specifically designed for API authentication and can be scoped to grant specific permissions.
How Do PATs Work Internally?
When you generate a PAT in the DigitalOcean control panel, you’re essentially creating a long, random string of characters. This string is associated with your account and a set of defined scopes.
When you include this token in the Authorization: Bearer <token> header of an API request:
- DigitalOcean receives the request.
- It extracts the token from the
Authorizationheader. - It looks up the token in its system to identify the associated user account and its permissions (scopes).
- It checks if the requested API action (e.g., listing Droplets, creating a Droplet, revoking access) is permitted by the token’s scopes.
- If authorized, the action proceeds. If not, a
403 Forbiddenerror is returned.
The "Bearer" part of the Authorization header is a standard for token-based authentication, indicating that the token itself grants access.
The Levers You Control: Scopes
The most critical aspect of PATs is their scopes. When you create a PAT, you must choose which permissions it will have. This is crucial for security. You should always grant only the minimum permissions necessary for the task.
Common scopes include:
read: Allows reading (GET) data for resources.write: Allows creating, updating, and deleting (POST, PUT, DELETE) resources.account: Allows reading account-specific information.billing: Allows reading billing information.actions: Allows initiating and reading account actions.projects: Allows managing projects.2fa: Allows managing two-factor authentication.
For example, if you’re creating a script that only needs to list your Droplets, you would generate a PAT with only the droplets:read and read scopes. If the script also needs to create Droplets, you’d add droplets:write. A PAT with write scope can perform read actions as well.
Generating a PAT
- Log in to your DigitalOcean account.
- Navigate to API in the left-hand menu.
- Click on Tokens/Keys.
- Under Personal Access Tokens, click Generate New Token.
- Give your token a descriptive name (e.g.,
my-droplet-manager-script). - Select the desired Scopes. For most common tasks, you’ll want
readandwrite. Be specific if you only need read access. - Click Generate Token.
- Crucially, copy the token immediately. It will only be shown to you once. Store it in a secure place, like a password manager or a secure vault.
Using a PAT with doctl
While curl is great for understanding, the doctl command-line tool is the recommended way to interact with DigitalOcean. doctl uses PATs for authentication.
After generating your PAT, you can configure doctl to use it:
doctl auth init --token YOUR_PERSONAL_ACCESS_TOKEN
Once initialized, doctl will store this token securely (usually in ~/.config/doctl/config.yaml) and use it automatically for all subsequent commands. For instance, to list Droplets:
doctl compute droplet list
This command internally uses the PAT you provided during doctl auth init to authenticate with the DigitalOcean API.
The One Thing Most People Don’t Know
When you generate a Personal Access Token with write scope, it implicitly grants read scope as well. You don’t need to explicitly select read if you’ve selected write for the same resource type. The API treats write as a superset of read. This is a common point of confusion, leading some users to over-select scopes unnecessarily, or to wonder why a write token can also perform read operations.
Next Steps
Once you’re comfortable generating and using PATs for basic API interactions, you’ll likely want to explore more advanced use cases, such as integrating them into CI/CD pipelines or using them with Infrastructure as Code tools like Terraform.