Skip to content
Latchkey

What Is Authentication? Proving Who You Are

Authentication answers one question: are you who you say you are? It verifies an identity before any access is granted.

Authentication is the front door of every secure system. Before a person, service, or pipeline can do anything, it must prove its identity, usually by presenting something it knows, has, or is. In CI/CD this matters constantly: a pipeline authenticates to GitHub, to a cloud provider, and to a registry, often dozens of times per run, all without a human typing a password.

The three factors

  • Something you know: a password, PIN, or passphrase.
  • Something you have: a phone, hardware key, or token.
  • Something you are: a fingerprint, face, or other biometric.

Authentication is not authorization

Authentication establishes identity; authorization decides what that identity is allowed to do. Logging in proves who you are. Whether you can delete a production database is a separate authorization question. Conflating the two is a common source of security bugs.

How machines authenticate

Most CI work is machine-to-machine. A pipeline does not type a password; it presents a token, an API key, or a short-lived credential minted on demand. The receiving service validates that credential and decides whether to trust the request.

Authentication in CI/CD

A single workflow run authenticates many times: to clone the repo, push an image, deploy to a cloud account, and report status back. Each step needs a credential, and each credential is a thing that can leak. Minimizing standing credentials, for example by using OIDC to mint per-job tokens, shrinks that risk.

Common failure modes

Weak or reused passwords, long-lived tokens that never rotate, and credentials checked into source control are the usual ways authentication breaks. In pipelines, a leaked token is especially dangerous because it often carries broad, automated access.

Why the runner matters

Authentication credentials pass through whatever machine runs the job. On a shared, long-lived runner, a leaked token can linger and be read by a later job. Isolated, ephemeral runners (such as Latchkey managed runners) destroy the environment after each job, so credentials do not outlive the work that used them.

Key takeaways

  • Authentication proves an identity is genuine before access is granted.
  • It is distinct from authorization, which governs what an identity may do.
  • In CI/CD, machine authentication is constant; short-lived credentials reduce leak risk.

Related guides

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