Authentication overview

Access to the GitHub API, encompassing both its REST and GraphQL interfaces, requires authentication to ensure secure and authorized interactions. This process verifies the identity of the user or application making a request, granting access based on predefined permissions. GitHub supports several authentication methods, each designed for different use cases, from personal scripting to large-scale third-party integrations.

Choosing the appropriate authentication method is crucial for balancing security, functionality, and ease of implementation. Factors to consider include the type of application (personal script, web application, CI/CD tool), the scope of access required, and the desired level of user interaction for authorization. All authentication methods rely on credentials generated within GitHub's developer settings or through an OAuth flow, allowing for fine-grained control over permissions via scopes or permissions policies.

Supported authentication methods

GitHub API offers multiple methods for authentication, catering to various integration scenarios. Each method has specific strengths and is best suited for particular types of applications or workflows. Understanding these differences is key to implementing secure and efficient API access.

1. Personal Access Tokens (PATs)

Personal Access Tokens (PATs) are strings of characters that act as alternative passwords for authenticating to GitHub when using the API or Git command-line. They are user-specific and can be configured with specific scopes, which define the permissions the token grants. PATs are suitable for scripting, command-line tools, and personal integrations where an application needs to act on behalf of a single user.

2. OAuth Apps

OAuth Apps are designed for client-server applications that interact with users' GitHub data on their behalf. This method utilizes the OAuth 2.0 protocol, allowing users to authorize an application to access their GitHub resources without sharing their username and password directly with the application. OAuth Apps are ideal for web applications, mobile apps, and other third-party services that need to request user consent for access to public and private data.

3. GitHub Apps

GitHub Apps are the recommended method for building integrations that automate workflows, extend GitHub's functionality, or integrate with external services. Unlike OAuth Apps, GitHub Apps act as first-class actors within GitHub, giving them direct access to an organization's resources without impersonating a user. They offer granular permissions, built-in rate limits, and are designed for long-lived integrations that require fine-tuned control over access. GitHub Apps can be installed on repositories, organizations, or user accounts.

4. SSH Keys

While primarily used for Git operations, SSH keys can also be used for certain API interactions, particularly when using Git over SSH. Authentication via SSH keys is typically limited to repository operations (push, pull) and is less common for general REST API calls compared to PATs or GitHub Apps. SSH keys provide a secure way to authenticate a client to a server using cryptographic keys, as detailed in the SSH protocol specification.

The following table provides a comparison of these authentication methods:

Method When to Use Security Level Key Feature
Personal Access Tokens (PATs) Scripts, CLI tools, personal automation Medium (depends on scope management) User-specific access, granular scopes
OAuth Apps Web applications, mobile apps, third-party services requiring user authorization High (user consent flow) Delegated authorization via OAuth 2.0
GitHub Apps Long-lived integrations, automation, extending GitHub functionality High (fine-grained permissions, installation-based) First-class actor, per-installation permissions
SSH Keys Git operations over SSH High (cryptographic key pair) Secure Git access, less common for general API

Getting your credentials

The process for obtaining credentials varies depending on the chosen authentication method:

For Personal Access Tokens (PATs):

  1. Navigate to your GitHub account settings.
  2. Go to "Developer settings" > "Personal access tokens".
  3. Click "Generate new token" or "Generate new token (classic)". GitHub's documentation on PAT creation provides detailed steps.
  4. Provide a descriptive name for the token.
  5. Select the scopes (permissions) required for the token. Only grant the minimum necessary permissions.
  6. Click "Generate token".
  7. Copy the token immediately, as it will not be shown again.

For OAuth Apps:

  1. Register a new OAuth App in your GitHub developer settings under "OAuth Apps".
  2. Provide the application name, homepage URL, description, and crucial authorization callback URL(s).
  3. GitHub will provide a "Client ID" and "Client Secret". These are your application's credentials.
  4. Implement the OAuth web application flow: redirect users to GitHub for authorization, handle the callback, and exchange the authorization code for an access token.

For GitHub Apps:

  1. Register a new GitHub App in your GitHub developer settings under "GitHub Apps".
  2. Configure the app's name, description, URL, callback URL, and critically, the permissions and subscribed events.
  3. Generate a private key for your GitHub App. This key is used to sign JSON Web Tokens (JWTs) for authenticating the app.
  4. GitHub will provide an "App ID" and "Client ID".
  5. Implement the installation flow, allowing users or organizations to install your app and grant it permissions.
  6. Use the private key to generate a JWT, then exchange the JWT for an installation access token. This token is used to make API requests on behalf of the installation.

For SSH Keys:

  1. Generate an SSH key pair on your local machine if you don't already have one. This typically involves using ssh-keygen.
  2. Add the public SSH key to your GitHub account settings under "SSH and GPG keys". Details are available in the GitHub guide to adding SSH keys.
  3. Configure your Git client to use SSH for repository operations.

Authenticated request example

This example demonstrates how to make an authenticated request to the GitHub API using a Personal Access Token (PAT) via curl. The PAT is included in the Authorization header using the Bearer token scheme. This method is applicable for most REST API endpoints when using PATs or OAuth access tokens.

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  https://api.github.com/user

Explanation:

  • -L: Follows redirects.
  • -H "Accept: application/vnd.github+json": Specifies that the client prefers JSON data in the GitHub API format.
  • -H "Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN": This header contains the authentication credential. Replace YOUR_PERSONAL_ACCESS_TOKEN with your actual PAT. The Bearer scheme is standard for token-based authentication, as defined by RFC 6750 for OAuth 2.0 Bearer Token Usage.
  • -H "X-GitHub-Api-Version: 2022-11-28": Specifies the API version to ensure consistent behavior.
  • https://api.github.com/user: The endpoint to retrieve information about the authenticated user.

For GitHub Apps, the process involves generating a JWT with your private key, then using that JWT to obtain an installation access token, which is then used in the Authorization: Bearer header similar to a PAT.

Security best practices

Adhering to security best practices when authenticating with the GitHub API is essential to protect your data and prevent unauthorized access:

  • Use the Principle of Least Privilege: Always grant the minimum necessary permissions (scopes) to your tokens or apps. If a token only needs to read public repositories, do not grant it write access to private ones. Regularly review and adjust permissions as needs change.
  • Store Credentials Securely: Never hardcode PATs, client secrets, or private keys directly into your code. Use environment variables, secure configuration files, or dedicated secret management services (e.g., AWS Secrets Manager, Azure Key Vault, HashiCorp Vault).
  • Rotate Credentials Regularly: Periodically revoke and generate new PATs and client secrets. This reduces the risk exposure if a credential is compromised. Consider automating this process where feasible.
  • Monitor for Suspicious Activity: Regularly review audit logs for your GitHub account and organizations for any unusual API activity or unauthorized access attempts.
  • Use Specific Tokens for Specific Tasks: Instead of using one highly privileged PAT for everything, create multiple PATs, each with minimal scopes, for different applications or scripts. This limits the blast radius if one token is compromised.
  • Avoid Sharing Credentials: Never share your personal access tokens or application secrets with others. Each developer or application should have its own set of credentials.
  • Implement IP Whitelisting (where available): For GitHub Apps and some enterprise features, you might be able to restrict API access to a specific set of IP addresses, adding an extra layer of security.
  • Use HTTPS: Always ensure that all API requests are made over HTTPS to encrypt data in transit and prevent eavesdropping. GitHub API inherently enforces HTTPS.
  • Understand Rate Limits: While not strictly an authentication practice, being aware of and handling GitHub API rate limits prevents service disruptions and indicates proper API usage patterns, indirectly contributing to operational security by avoiding denial-of-service-like behaviors.
  • Leverage GitHub Apps for Integrations: For robust, production-grade integrations, prioritize GitHub Apps over OAuth Apps or PATs. They offer superior security models, granular permissions, and are designed for long-term, scalable solutions.