Implement and manage GitHub authentication

Three mechanisms, in descending order of preference.

Start with GITHUB_TOKEN

Every workflow run gets one automatically. It is scoped to the repository, its permissions are declarable per workflow or job, and it expires when the job finishes — so there is no credential to store and nothing to rotate.

Declaring permissions explicitly narrows the token. This is the cheapest security win in GitHub Actions: default permissions are broader than most jobs need.

When GITHUB_TOKEN is not enough

If a workflow needs permissions the automatic token cannot carry — acting across repositories, for instance — the documented options are to create a GitHub App and generate an installation access token within the workflow, or to store a personal access token as a secret.

Prefer the App. A PAT belongs to a person: it carries that person's access, breaks when they leave, and is a long-lived credential sitting in a secret store. An App is an identity in its own right with its own narrowly scoped permissions.

Primary sources

• https://docs.github.com/en/actions/tutorials/authenticate-with-github_token
• https://docs.github.com/en/actions/concepts/security/openid-connect