Authentication answers one question: "Who are you?" It is the process of verifying that a user (or system) is who they claim to be. Applications do not invent identity-they check it using something you know (password), something you have (phone, token), or something you are (fingerprint, face).

These three categories are called "authentication factors." Single-factor authentication uses one (like a password). Multi-factor authentication (MFA) combines two or more factors, making it much harder for attackers to impersonate you.

The illustration shows various authentication methods working together: biometric authentication (fingerprint), password entry, hardware tokens (USB key), and secure access through a gateway. Each method represents a different authentication factor, and combining them creates stronger security.

When you log in, the app compares what you submit (e.g. username + password) against stored credentials. If they match, the app creates a session or issues a token so it can recognize you on later requests without asking again.

The authentication flow typically involves: (1) User submits credentials, (2) Application validates against stored data, (3) If valid, a session or token is created, (4) Subsequent requests use this session/token for authentication.

Passwords are the most common factor but are weak alone. They can be guessed, stolen, or reused across sites. Modern applications use password hashing (like bcrypt) to store passwords securely-they never store the actual password, only a one-way hash.

Tokens (temporary codes or JWTs) let an app trust that you already proved your identity elsewhere. OAuth tokens, for example, let you "Login with Google" without giving the app your Google password. The app trusts Google's authentication.

Multi-factor authentication (MFA) adds a second step-like a code on your phone-so stealing one factor is not enough. Even if someone gets your password, they can't log in without your phone. Understanding these ideas helps you see how any cloud or on-prem system implements login.

After successful authentication, applications need a way to remember you. Two common approaches are sessions and tokens.

Sessions store authentication state on the server. Your browser gets a session ID (usually in a cookie), and the server looks up your session to verify you're logged in. This works well for traditional web apps but requires server-side storage.

Tokens (like JWTs) are self-contained. They encode your identity and permissions, and the app can verify them without checking a database. This makes them great for APIs and distributed systems. Tokens can expire and be refreshed, providing security while maintaining convenience.

JSON Web Tokens (JWTs) are a popular way to represent identity and claims in a compact, URL-safe format. A JWT has three parts separated by dots: header.payload.signature. Each part is Base64URL-encoded text.

The header describes how the token is secured (for example which signing algorithm is used). The payload carries claims about the user and context (such as user id, roles, and expiration time). The signature lets the server verify that the token was issued by a trusted party and has not been tampered with.

Understanding what lives in each part of a JWT helps you debug authentication problems, validate tokens safely, and recognise when sensitive data is being put in the wrong place (for example, secrets should never be stored in the payload).

Single sign-on (SSO) lets you log in once and access multiple applications. Instead of each app managing its own users, they delegate authentication to a trusted identity provider (like Google, Microsoft, or Okta).

OAuth is a protocol that enables SSO. When you click "Login with Google," your app redirects you to Google, you authenticate there, and Google gives your app a token saying "this user is authenticated." The app never sees your Google password.

This pattern appears everywhere: cloud providers use it for their services, enterprise software uses it for employee access, and consumer apps use it for convenience. Understanding SSO helps you work with any modern authentication system.

Authentication is the foundation of security. Without it, anyone could access anyone else's data. But authentication alone isn't enough-you also need authorization (deciding what authenticated users can do).

In cloud environments, authentication becomes even more critical. Services need to authenticate each other (service-to-service authentication), not just users. API keys, service accounts, and mutual TLS are common patterns for this.

Whether you're building an app, configuring cloud services, or managing infrastructure, understanding authentication helps you make security decisions and troubleshoot access issues.