4 Authentication Mechanisms

Authentication answers a narrow question: how does a system decide who is making a request? In production, the answer is usually layered. A user may start with a password, receive a session cookie, and later approve an OAuth flow so another application can act on their behalf. Each mechanism fits a different trust boundary, revocation model, and operational burden.

1. Passwords

Passwords remain common because they are cheap to deploy and familiar to users. A user proves identity by demonstrating knowledge of a shared secret that the server can verify. In a sound design, the server never stores the password itself. It stores a slow password hash with a unique salt and compares future login attempts against that derived value.

The security problem is not only guessing a password. Real systems need defences around the full lifecycle: rate limiting, breached-password checks, reset tokens, recovery flows, and phishing resistance. Passwords are also weak against credential stuffing because attackers reuse leaks from other services. That is why passwords alone are rarely enough.

2. Session cookies

Session cookies are the dominant mechanism for browser applications after the initial login. The server authenticates the user once, creates a session record, and sends the browser a session identifier in an HTTP-only cookie. On later requests, the cookie points the server back to that session state.

This approach fits web applications because revocation is simple. Delete the session server-side and the cookie stops being useful. It also keeps sensitive identity state off the client if the cookie carries only an opaque ID.

The main constraints are scaling and browser security. A large deployment needs shared session storage or a design that routes repeat requests to a node that can validate the session. Cookies also bring cross-site request forgery concerns, so SameSite, CSRF tokens, secure transport, and domain scoping matter.

3. OAuth 2.0 and OpenID Connect tokens

OAuth 2.0 is a delegation framework, and OpenID Connect layers identity on top of it. Together they allow an application to redirect a user to an identity provider, receive tokens, and use those tokens to call APIs or establish the user identity.

This is the standard choice for enterprise single sign-on, social login, and third-party API access because it separates the application from direct credential handling. An identity provider can enforce multi-factor authentication, account recovery, and federation rules once for many applications.

The complexity moves into token handling. Access tokens expire, refresh tokens must be protected, scopes must match least privilege, and every consumer needs to validate issuer, audience, and signature correctly. Teams also need to distinguish identity tokens from API authorisation tokens.

4. Public-key and certificate-based authentication

Public-key authentication proves possession of a private key instead of knowledge of a shared secret. SSH keys, WebAuthn authenticators, signed client assertions, and mutual TLS certificates all follow that model. The server verifies a signature or certificate chain with the corresponding public key.

This approach is strong because the private key does not cross the network, and phishing resistance can be much better than with passwords. It is especially useful for device identity, admin access, and service-to-service authentication where keys and certificates can be provisioned automatically.

The operational burden sits in issuance and rotation. Keys need secure storage, certificates need expiry management, and revocation has to work during incidents. Most mature systems therefore combine mechanisms instead of choosing one winner. The practical question is which method matches the actor, client platform, threat model, and revocation needs of the system you actually run.