👋 Hey there!

Scenario: You need to automate something in GitHub, and after a couple of searches in Google, you see that you can create a PAT and use that.

Sure, that will work, but there is a much better way.

What's wrong with PAT?

User Association and Security Concerns

PATs are associated with a user, which means anyone can generate one, and all usage, commits, pull requests, issues, etc, will be related to that user. The lack of granularity in permissions also means they might have more permissions than necessary for a specific task, thereby increasing security risks.

Audit trail issues arise when multiple people use the same PAT, as tracing actions back to an individual becomes difficult, complicating security audits and accountability.

Expiry and Automation Challenges

The challenges in automating the renewal process of PATs contribute significantly to the human reluctance to set expiry dates. This oversight leads to the use of long-lived tokens, which pose a significant security risk. The longer a token exists without renewal or review, the more vulnerable it becomes to potential leaks and unauthorized use.

Set and Forget - Oversight Risks

The "set and forget" nature of PATs can lead to significant oversight, particularly in access review. It's common to overlook the necessity of reviewing and revoking PATs, especially when employees depart or change roles within an organization.

Additionally, there's the potential for escalating access. If a user's permissions are elevated after a PAT is created, the token might inadvertently grant more access than intended without any subsequent review. This can lead to unintentional access escalation, further compounding security vulnerabilities.

One frustrating thing about GitHub is that you can't turn off the use of them. Fine-grained tokens exist but have been in Beta for ages and don't work with some services

The Better Way - GitHub Apps

A better way to provide authentication is using GitHub apps, as they will and always have allowed you to provide fine-grained access via RBAC.

GitHub Apps can generate short-lived credentials that we can use in our CI/CD processes. There is even a GitHub Action available.

https://github.com/actions/create-github-app-token

This can be used as follows with the GitHub App ID and the Private Key:-

- uses: actions/create-github-app-token@v1
id: app-token
with:
    app-id: ${{ secrets.app_id }}
    private-key: ${{ secrets.app_pem_file }}
    owner: 'myorganisation'

A Key part of the process is the creation of the JSON Web Token (JWT)

What is a JWT

A JWT token, acts like a special access pass, allowing applications or scripts to interact with GitHub resources securely.

It's a compact, URL-safe means of representing claims between two parties. A JWT is often utilized for authentication by GitHub Apps, granting them a secure way to prove their identity and access permissions.

The token comprises encoded JSON objects, including details like the App's identifier and an expiration timestamp, ensuring the token is used within a valid timeframe.

Once generated and signed with the App's private key, this token can be sent to GitHub to authenticate API requests. This method ensures that only authorized actions are performed, keeping both the GitHub resources and the user data safe and secure.

GitHub App Authentication Process

The authentication process for GitHub Apps using the create-github-app-token GitHub Action involves several steps, primarily centred around generating a temporary installation access token.

GitHub App Creation: Initially, you create a GitHub App in your GitHub account. This App is granted specific permissions and can be installed on repositories.

App Installation: The GitHub App is installed on a repository (or repositories), and an installation ID is generated.

Generate Private Key: A private key is generated for the GitHub App and downloaded. This key is used to authenticate as the GitHub App.

Action Execution: When the create-github-app-token GitHub Action runs, it requires the App ID, the installation ID, and the private key.

JWT Generation: The action generates a JSON Web Token (JWT) using the App's private key. This JWT is used to authenticate as the GitHub App itself, not as a user.

Retrieve Installation Access Token: The JWT is then used to request a temporary installation access token from the GitHub API for the specified installation ID.

Use Token for API Access: This installation access token can be used to perform actions on the repository according to the permissions granted to the GitHub App.

Token Expiration: The installation access token is short-lived (usually valid for an hour), after which it expires, and a new token needs to be generated for further operations.

Summary

This post explains the use of GitHub Apps over Personal Access Tokens. Hopefully, it will make you think twice about defaulting to using a PAT next time you think you have the need.

I hope this helps someone else!

Cheers