Back

What is authentication?

How applications verify identity-concepts that apply everywhere.

Identity vs. verification

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.

Authentication Factors?Something you KNOWPasswordPINSecret QuestionSomething you HAVEPhone / SMSHardware TokenSmart CardSomething you AREFingerprintFace RecognitionIris ScanMulti-Factor Authentication

How it works in applications

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.

1

User Submits

Username + Password

2

App Validates

Checks credentials

3

Session/Token

Created if valid

4

Authenticated

Future requests use token

πŸ”„

Alternative: SSO/OAuth Flow

Instead of username/password, users can authenticate via third-party providers (Google, Microsoft, GitHub). The app redirects to the provider, user authenticates there, and the provider gives your app a tokenβ€”no password handling required.

Passwords, tokens, and more

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.

Password Security Best Practice

Modern apps never store plaintext passwords. Instead, they use one-way hashing algorithms like bcrypt, argon2, or scrypt. When you log in, the app hashes your input and compares it to the stored hashβ€”if they match, you're authenticated.

This means even if attackers breach the database, they can't reverse-engineer your password from the hash.

Password

Single factor

+ Phone

Two factors

+ Biometric

Three factors

Why MFA Matters

Even if someone steals your password, they can't log in without your phone or fingerprint. MFA reduces account compromise by 99.9% compared to passwords alone.

Sessions vs. tokens

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.

Sessions (classic web apps)

  • β€’ Server stores session data in memory or a cache
  • β€’ Browser holds an opaque session ID cookie
  • β€’ Easy to revoke by deleting the session server-side

Tokens (APIs & distributed systems)

  • β€’ JWT or opaque token sent on every request
  • β€’ Contains identity/claims; server can verify without DB
  • β€’ Great for microservices and mobile / SPA clients

Real-world scenario: banking app login

Expert scenario

Scenario: You are building a banking app and a user logs in from a new device in a different country.

Decision: Even if the password is correct, you trigger step-up authentication. The app asks for an extra factor-like an SMS code, push notification, or biometric check-because the context (new device + unusual location) looks risky.

This is how strong systems combine authentication factors with context signals (IP, device fingerprint, geo-location) to protect high-value accounts.

JWT anatomy: header, payload, signature

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).

Example JWT

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkppbSIsImV4cCI6MTcxNzAwMDAwMH0.YmFzZTY0dXJsLXNpZ25lZC1ieS1zZWNyZXQta2V5

Header

Small JSON object that says how the token is secured.

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload (claims)

Contains who the user is and any extra claims. This part is encoded, not encrypted.

{
  "sub": "1234567890",
  "name": "Jim",
  "exp": 1717000000
}

Signature

Cryptographic proof that the header and payload were issued by a trusted party and not changed.

signature = HMACSHA256(base64Url(header) + "." + base64Url(payload), secret)

Servers verify this with a secret key (HS256) or a public key (RS256/ES256).

Single sign-on (SSO) and OAuth

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.

OAuth 2.0 Flow (Simplified)

1

User clicks "Login with Google" in your app

2

App redirects to Google's login page

3

User authenticates with Google (your app never sees the password)

4

Google gives your app a token saying "this user is authenticated"

Key benefit: Your app trusts Google's authentication without handling passwords. This is SSO in action.

πŸ”

No Password Sharing

App never sees user's password

🌐

Works Everywhere

Google, Microsoft, GitHub, etc.

⚑

One Login

Access multiple apps

Why authentication matters

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.

User Authentication

Traditional login flows: passwords, MFA, sessions, tokens

Service-to-Service Auth

APIs authenticate each other using API keys, service accounts, mutual TLS

Sign in to track progress on your dashboard.

Ready to see how this works in the cloud?

Switch to Career Paths on the Academy page for structured paths (e.g. Developer, DevOps) and provider-specific lessons.

View role-based paths