Authentication

Authentication is the process of verifying the identity of a user, device, or system. It answers the question "who are you?" by checking that a claimed identity is genuine.

Authentication is distinct from authorization, which decides what an authenticated principal is allowed to do. The two are separate concerns, but so often implemented together that they are collectively known as identity and access management (IAM).

Authentication factors

An authentication factor is a piece of evidence used to confirm an identity. There are three classical categories.

Knowledge. Something the principal knows, eg. a password, PIN, or the answer to a secret question.
Possession. Something the principal owns, eg. a hardware security key, a smart card, or a one-time code from an authenticator app.
Inherence. Something that is inherent to the principal, eg. a fingerprint, a face scan, or another biometric trait.

Multi-factor authentication (MFA), also known as two-factor authentication (2FA), requires evidence from two or more of these categories. The premise is that an attacker who compromises one factor – a leaked password, say – still cannot authenticate without at least a second factor.

Common mechanisms

Authentication systems vary widely in how they collect and validate evidence.

Passwords remain the dominant knowledge factor. But, because users reuse and choose weak passwords, password-based systems are often paired with secondary controls, including rate limiting to throttle brute-force guessing, salts and slow hash functions to protect stored credentials, and MFA to compensate for the inherent weakness of memorized secrets.

Tokens replace a long-lived credential with a short-lived proof of identity issued after an initial login. JSON Web Tokens carry signed claims about the user and are verified by the server without a session lookup, which makes them popular in distributed and API gateway-mediated architectures.

Certificates rely on public-key cryptography. The principal proves possession of a private key whose corresponding public key is vouched for by a trusted certificate authority. Mutual TLS (mTLS) authenticates both ends of a connection this way, and is common in service-to-service communication.

Federated protocols delegate authentication to an external identity provider. OAuth 2.0 and OpenID Connect let a relying party accept an identity attested by a trusted authority, enabling single sign-on (SSO) – one login that works across many services.

Sessions versus tokens

After a principal is authenticated, the server must remember that fact for the duration of the interaction. Two dominant models exist.

Session-based. The server stores authenticated state and issues the client an opaque session identifier, typically carried in a cookie. Each subsequent request triggers a server-side lookup to verify the session is valid and not expired.

Token-based. The server issues a self-contained, signed token (eg. a JWT) that the client presents on every request. The server validates the token’s signature rather than looking up state.

The trade-off is state versus revocation. Sessions are easy to revoke but require shared state in distributed deployments. Tokens scale horizontally but are hard to revoke before they expire, so they are usually short-lived and paired with longer-lived, revocable refresh tokens. Where instant revocation matters, an opaque token – a random reference with no readable content – can be checked against the issuer on each use, through a mechanism called token introspection, trading the scalability of local validation for control.

Where a token is stored on the client matters. In web applications, localStorage and sessionStorage are readable by any script on the page and so are vulnerable to cross-site scripting (XSS). HttpOnly cookies are not accessible to scripts and are safer against theft, but they require protection against cross-site request forgery (CSRF).

Authentication across trust boundaries

A request that crosses from one trust domain to another – user to application, application to API, service to service, or organization to organization – must prove identity at each crossing. Different boundaries call for different mechanisms.

OAuth 2.0 and OpenID Connect

OAuth 2.0 is a delegated authorization framework that issues access tokens. OpenID Connect (OIDC) adds an authentication layer on top, issuing an ID token that states who the user is. The two are often conflated, but OAuth 2.0 alone says what a client may do, not who the user is.

The main flows are:

Authorization Code with PKCE. The standard for web, mobile, and single-page applications. The older implicit flow is now discouraged.
Client Credentials. For machine-to-machine calls where no user is involved.

Service-to-service authentication

Within a system, services authenticate each other with mTLS, where both sides present certificates. A service mesh automates this, and SPIFFE/SPIRE provides standard, verifiable workload identities. Cloud platforms offer workload identity (IAM roles, managed identities) so that services avoid long-lived secrets entirely.

Propagating user identity

When service A calls service B on a user’s behalf, forwarding the user’s original token everywhere widens the blast radius if it leaks. Better options are token exchange (RFC 8693) or on-behalf-of flows, which mint a new token scoped to the downstream service, with the right audience. A common pattern is for an API gateway to validate external tokens at the edge and pass a trusted internal identity inward.

Federation and single sign-on

Federation lets one organization trust another’s identity provider. SAML is common in older enterprise setups and OIDC in newer ones. Single sign-on relies on federation so that users log in once and gain access to many systems.

Zero trust

The zero trust stance is "never trust the network". Every request is authenticated and authorized, even inside the perimeter, rather than trusting anything that sits behind the firewall.

Operational concerns

Store secrets in a secrets manager (eg. HashiCorp Vault, AWS Secrets Manager), not in code or configuration.
Rotate keys and certificates regularly.
Allow for clock skew, since token expiry depends on synchronized clocks.

Common attacks and defenses

Credential stuffing and brute force. Automated attempts to validate large sets of stolen credentials. Mitigated with rate limiting, account lockout thresholds, and MFA.
Phishing. Deception that tricks a user into entering credentials on a fake site. Mitigated with phishing-resistant factors such as hardware keys and FIDO2, and with targeted user training.
Session hijacking. Theft of a valid session identifier or token. Mitigated with HTTPS, short token lifetimes, and secure cookie attributes.
Replay. Re-transmission of a captured token or request. Mitigated with nonces, timestamps, and short-lived tokens.
Confused deputy. A service with legitimate privileges is tricked into using them on behalf of a caller who lacks them. Mitigated by propagating the caller’s identity rather than acting solely under the service’s own.
Token leakage. Tokens written to logs, URLs, or error messages. Mitigated by redacting credentials from logs and never carrying tokens in query strings.
Missing audience checks. A token issued for one service is replayed against another. Mitigated by validating the aud claim on every token.

A secure by design approach treats these threats as design constraints from the outset, rather than patches applied after deployment.