Skip to content
Latchkey

What Is Authorization? Deciding What You Can Do

Authorization is the gate after the front door: once a system knows who you are, it decides what you are allowed to do.

Authorization is the enforcement of permissions. After authentication confirms an identity, authorization checks whether that identity may perform a specific action on a specific resource. In CI/CD, authorization is what stops a test pipeline from deploying to production or a read-only token from pushing code.

Authentication versus authorization

Authentication answers "who are you"; authorization answers "what may you do." You can be authenticated and still be denied an action. Good systems keep these concerns separate and check authorization on every sensitive operation, not just at login.

How permissions are modeled

  • Role-based: permissions attached to roles, roles assigned to identities.
  • Attribute-based: rules evaluated against attributes of the user, resource, and context.
  • Access control lists: explicit per-resource lists of who may do what.

Scopes and tokens

In automated systems, authorization is often baked into the token itself through scopes. A token scoped to read-only cannot write, even if it leaks. Narrow scopes are a primary defense in CI, because a pipeline token tends to run unattended with broad reach.

Least privilege in pipelines

The safest default is to grant a job exactly the permissions it needs and nothing more. A workflow that only runs tests should not hold deploy credentials. GitHub Actions, for example, lets you set the GITHUB_TOKEN permissions per job so a step cannot do more than its task requires.

When authorization fails

Over-broad tokens, missing checks on internal endpoints, and privilege escalation through misconfigured roles are common failures. In CI, the classic mistake is one powerful credential reused everywhere, so a single leak grants attackers everything.

Authorization and the runner

A runner inherits whatever a job is authorized to do. Scoping job permissions tightly limits the blast radius if a runner is compromised. Ephemeral, isolated runners (such as Latchkey managed runners) further contain that radius by not carrying authorization context between jobs.

Key takeaways

  • Authorization governs what an authenticated identity is permitted to do.
  • Role-based, attribute-based, and ACL models are the common ways to express it.
  • Least-privilege scoping of pipeline tokens limits damage from a leak.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →