4.1.1.3. PATs, GitHub Apps, and Authentication Hierarchy
4.1.1.3. PATs, GitHub Apps, and Authentication Hierarchy
RBAC governs Azure resource access; PATs and GitHub Apps govern access to DevOps platform features like repositories and pipelines.
Personal Access Tokens (PATs) provide user-scoped authentication for Azure DevOps and GitHub APIs. While convenient, PATs carry significant security risk: they represent a user's permissions, can be overly broad, and require manual rotation. Always set the shortest viable expiration and narrowest scope. GitHub Apps offer a better model for programmatic access — they authenticate as an installation (not a user), have granular repository-level permissions, and use short-lived installation tokens that auto-expire. OAuth apps authenticate on behalf of users and inherit their permissions, appropriate for user-facing integrations but risky for automation. The hierarchy of preference for pipeline authentication: managed identity (no credentials) > workload identity federation (OIDC, no stored secrets) > GitHub App (short-lived tokens) > service principal with secret (must rotate) > PAT (user-scoped, risky).
Content for Assign Role - see flashcards and questions for this subsection.
The authentication method hierarchy reflects a security vs. convenience trade-off. GitHub Apps occupy a middle position — more secure than PATs (installation-scoped, short-lived tokens) but requiring more setup. A GitHub App authenticates as an installation, not a user, with permissions scoped to specific repositories and specific actions (read code, write issues, manage deployments). Installation tokens expire after 1 hour, minimizing exposure if compromised.
OAuth apps authenticate on behalf of a user, inheriting that user's permissions across all their repositories. This is appropriate for developer tools (IDEs, browser extensions) but inappropriate for automation — if the user leaves the organization, the OAuth app loses access. PATs share this user-binding problem and add the risk of overly broad scopes that developers set at creation time and never narrow.
For Azure DevOps, service connections are the preferred authentication mechanism for pipelines. They support managed identity, workload identity federation, and service principal authentication without exposing credentials in pipeline variables. Decorating service connections with appropriate check controls (approvals, branch restrictions) adds governance without complicating the authentication flow.
