devops-platform-authentication

GitHub and Azure DevOps authentication

What it is

GitHub and Azure DevOps use several authentication mechanisms: user sign-in, short-lived workflow tokens, GitHub Apps, personal access tokens (PATs), and service connections. Each represents a different identity and permission boundary.

Why it exists

Automation needs an identity, but treating every integration as a human PAT creates long-lived, overly broad credentials that are difficult to audit and revoke.

Key ideas

• Use GITHUB_TOKEN for workflow actions where its repository-scoped, configurable permissions are sufficient.
• Use a GitHub App for an installed integration that needs its own narrowly scoped identity across repositories or organizations.
• Use PATs only when required, with minimum scopes, expiration, secure storage, and rotation. Never put one in source code or logs.
• An Azure DevOps service connection is the authorization boundary for a pipeline to an external service. Design its identity, scope, approvals, and access separately from the YAML file.

Exam decision

Select the narrowest identity that fits the automation. A secretless cloud deployment identity, a repository workflow token, and a human PAT solve different authentication problems.

Related

secretless-pipeline-authentication · subscription-connection · pipeline-security

Sources: Automatic token authentication in GitHub Actions · Azure DevOps service connections