What are personal access tokens (PATs)?

A Personal Access Token (PAT) is a type of security credential that functions as an alternative to using a password for authentication. PATs are widely used in development environments to authenticate to services like GitHub, GitLab, or cloud platforms directly from scripts, command-line tools, or applications. They are long, randomly generated strings that a user can create to grant specific permissions (known as "scopes") to a third-party application or script without sharing their actual password.

Unlike passwords, PATs can be managed with much greater control. You can create multiple tokens for different applications, each with only the permissions necessary for its task. For example, you can create a token that only allows read access to your code repositories. Furthermore, PATs can be set to expire after a certain period and can be revoked at any time without affecting your main account password or other tokens, making them a more secure and flexible way to manage programmatic access.

In this lesson, you'll learn why PATs are a modern security best practice for developers. We'll cover their key benefits over passwords, walk through how to create a token securely on GitHub, and discuss the best practices for implementing them in your automation scripts and applications to prevent unauthorized access.

While using your password for programmatic access might seem convenient, it's a significant security risk. If a script or service containing your password is compromised, an attacker gains full access to your account. PATs were created to solve this problem by providing a more secure and controlled method of authentication. Their importance comes down to three key features:

Scoped permissions

When you create a PAT, you must assign it specific permissions, or "scopes." This aligns with the principle of least privilege. For example, if you have a script that only needs to read from a repository, you can create a token that only has read access. If that token is ever leaked, an attacker can't use it to write malicious code to your repository. This granular control is impossible with a password, which grants all-or-nothing access.

Revocability

Each PAT is a unique, standalone credential. If you suspect a token has been compromised or is no longer needed, you can revoke it instantly without affecting your password or any other tokens. This allows you to quickly shut down a potential security breach for a single application or service without disrupting everything else.

Expiration dates

Good security hygiene involves rotating credentials regularly. PATs make this easy by allowing you to set an expiration date upon creation. You can create a short-lived token for a one-time task or set a recurring expiration date for ongoing processes. This automatically limits the window of opportunity for an attacker if a token is ever exposed.

Creating a PAT is only half the battle! Using it securely is just as important. The fundamental rule is to treat your tokens like passwords and never store them in your source code. Hardcoding a token into a script and committing it to a repository is the most common way PATs are leaked.

The best practice is to store the token in a secure location and load it into the application's environment at runtime.

To run this script, a developer would first set the environment variable in their terminal or CI/CD system's secret store:

export GITHUB_PAT="ghp_aBcDeFgHiJkLmNoPqRsTuVwXyZ1234567890"

This way, the secret is decoupled from the code. If the code is made public, the token remains safe.

While PATs are great for personal scripts and automation, another authentication method exists for third-party applications: OAuth. Understanding the difference is key to choosing the right tool.

Personal Access Tokens (PATs): Best for personal use. Think of CI/CD scripts, command-line tools, or personal automation. The token is tied directly to your user account.

OAuth Apps: Best for third-party applications that need to act on your behalf (such as a code quality scanner that needs to comment on your pull requests). With OAuth, you aren't sharing a token directly. Instead, you authorize the application through a standard flow, and it receives a token that is tied to the application itself, not just your user.

Which is more secure? For third-party services, OAuth is the more secure and appropriate choice. The OAuth flow is designed specifically for delegated authority, providing a better user experience and a clearer security boundary. A user can see exactly which applications they have authorized and can revoke access from the application level.

Managing secrets is a critical skill for every developer. To learn more about best practices and the tools available, check out these resources:

• Snyk Docs: Authenticate to use the CLI with PATs and OAuth
• GitHub Docs: Managing your personal access tokens secure