Authentication & Security

The Big Picture

Here is the full authentication flow — from login to accessing a protected resource. Every arrow is a potential attack surface, which is why security matters at every step.

Authentication vs Authorization

These two words sound similar, but they solve completely different problems. Getting them confused is one of the most common mistakes in backend development. Let's break it down.

Session-Based Authentication

Sessions are the classic approach to keeping users logged in. Here's the flow, step by step:

1. User logs in — sends username + password to the server.
2. Server verifies credentials — checks against the database.
3. Server creates a session — stores session data (user ID, role, expiry) in memory, a database, or Redis.
4. Server sends a cookie — the response includes a Set-Cookie header with the session ID.
5. Client sends cookie on every request — the browser automatically includes the cookie.
6. Server looks up the session — reads the session ID from the cookie, finds the session data, and knows who the user is.

// Express.js session example
const express = require('express');
const session = require('express-session');

const app = express();

app.use(session({
  secret: 'your-secret-key',    // Signs the session cookie
  resave: false,                 // Don't save unchanged sessions
  saveUninitialized: false,      // Don't create empty sessions
  cookie: {
    httpOnly: true,              // JS can't access the cookie
    secure: true,                // HTTPS only
    maxAge: 1000 * 60 * 60 * 24 // 24 hours
  }
}));

// Login route
app.post('/login', async (req, res) => {
  const { username, password } = req.body;
  const user = await verifyCredentials(username, password);

  if (user) {
    req.session.userId = user.id;   // Store user ID in session
    req.session.role = user.role;
    res.json({ message: 'Logged in' });
  } else {
    res.status(401).json({ error: 'Invalid credentials' });
  }
});

// Protected route
app.get('/dashboard', (req, res) => {
  if (!req.session.userId) {
    return res.status(401).json({ error: 'Not authenticated' });
  }
  res.json({ message: `Welcome, user ${req.session.userId}` });
});

JWT (JSON Web Tokens)

JWTs flip the script on sessions. Instead of storing state on the server, the token itself contains all the information. The server signs the token, and the client sends it back on every request. The server verifies the signature — no database lookup needed.

Anatomy of a JWT

A JWT has three parts, separated by dots: header.payload.signature

# Decoded JWT structure
# HEADER (algorithm + type)
{
  "alg": "HS256",
  "typ": "JWT"
}

# PAYLOAD (claims — the actual data)
{
  "sub": "user123",
  "name": "Alice",
  "role": "admin",
  "iat": 1712000000,
  "exp": 1712086400
}

# SIGNATURE
HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

Creating and Verifying JWTs

const jwt = require('jsonwebtoken');

const SECRET = process.env.JWT_SECRET; // Never hardcode secrets!

// Create a token (on login)
function generateTokens(user) {
  const accessToken = jwt.sign(
    { userId: user.id, role: user.role },
    SECRET,
    { expiresIn: '15m' }  // Short-lived access token
  );

  const refreshToken = jwt.sign(
    { userId: user.id },
    SECRET,
    { expiresIn: '7d' }   // Long-lived refresh token
  );

  return { accessToken, refreshToken };
}

// Verify a token (middleware)
function authenticate(req, res, next) {
  const authHeader = req.headers.authorization;
  if (!authHeader) return res.status(401).json({ error: 'No token' });

  const token = authHeader.split(' ')[1]; // "Bearer "

  try {
    const decoded = jwt.verify(token, SECRET);
    req.user = decoded; // Attach user info to request
    next();
  } catch (err) {
    res.status(401).json({ error: 'Invalid or expired token' });
  }
}

// Protected route
app.get('/profile', authenticate, (req, res) => {
  res.json({ userId: req.user.userId, role: req.user.role });
});

Sessions vs JWT

OAuth 2.0

OAuth 2.0 solves a specific problem: how can a third-party app access your data without knowing your password? Think "Sign in with Google" — you never give the app your Google password. Instead, Google gives the app a limited access token.

The 4 Roles

Authorization Code Flow (Step by Step)

This is the most common and most secure OAuth flow. Here's what happens when you click "Sign in with Google":

// Step 1: Redirect user to authorization server
// Your app sends the user to Google's OAuth page
const authUrl = `https://accounts.google.com/o/oauth2/auth?
  client_id=YOUR_CLIENT_ID
  &redirect_uri=https://yourapp.com/callback
  &response_type=code
  &scope=email profile
  &state=random_csrf_token`;

// Step 2: User logs in and grants permission
// Google shows a consent screen. User clicks "Allow."

// Step 3: Auth server redirects back with an authorization code
// Google sends user to: https://yourapp.com/callback?code=AUTH_CODE&state=random_csrf_token

// Step 4: Exchange code for tokens (server-to-server, never in browser)
app.get('/callback', async (req, res) => {
  const { code, state } = req.query;

  // Verify state to prevent CSRF
  if (state !== expectedState) return res.status(403).send('CSRF detected');

  // Exchange authorization code for access token
  const tokenResponse = await fetch('https://oauth2.googleapis.com/token', {
    method: 'POST',
    headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    body: new URLSearchParams({
      code,
      client_id: process.env.GOOGLE_CLIENT_ID,
      client_secret: process.env.GOOGLE_CLIENT_SECRET,
      redirect_uri: 'https://yourapp.com/callback',
      grant_type: 'authorization_code'
    })
  });

  const { access_token, id_token } = await tokenResponse.json();

  // Step 5: Use the access token to call Google APIs
  const userInfo = await fetch('https://www.googleapis.com/oauth2/v2/userinfo', {
    headers: { Authorization: `Bearer ${access_token}` }
  });

  const user = await userInfo.json();
  // { id: "123", email: "[email protected]", name: "Alice" }
});

Password Security

Here's a truth that still surprises people: even big companies get breached. The question isn't if your database leaks, it's when. What matters is whether the attacker can read your users' passwords when it happens.

Why Never Store Plaintext

If you store passwords as plain text and your database is breached, every user's password is instantly compromised. Most people reuse passwords, so one breach cascades across all their accounts.

Hashing vs Encryption

Salt + Bcrypt

A salt is a random string added to the password before hashing. This means two users with the same password get different hashes. Bcrypt automatically generates and stores the salt.

import bcrypt

# Hashing a password (on registration)
password = "my_secure_password".encode('utf-8')
salt = bcrypt.gensalt(rounds=12)           # Cost factor: 2^12 iterations
hashed = bcrypt.hashpw(password, salt)
# b'$2b$12$LJ3m4ys3Lk0TBxvUZq8eNe...'

# Store `hashed` in the database (never the plain password)

# Verifying a password (on login)
login_password = "my_secure_password".encode('utf-8')
if bcrypt.checkpw(login_password, hashed):
    print("Login successful")
else:
    print("Invalid password")

HTTPS & Transport Security

HTTPS wraps HTTP in a TLS (Transport Layer Security) layer, encrypting everything between the client and server. Without it, anyone on the network (coffee shop Wi-Fi, ISPs, attackers) can read passwords, cookies, and tokens in plain text.

TLS Handshake (Simplified)

1. Client Hello — browser sends supported cipher suites and a random number.
2. Server Hello — server picks a cipher suite, sends its SSL certificate (contains public key).
3. Certificate Verification — browser checks the certificate against trusted Certificate Authorities (CAs).
4. Key Exchange — client and server agree on a shared symmetric key (using asymmetric crypto).
5. Encrypted Communication — all data is now encrypted with the shared key.

HSTS (HTTP Strict Transport Security)

HSTS tells browsers: "Never talk to me over HTTP. Always use HTTPS." This prevents downgrade attacks where an attacker intercepts the initial HTTP request before the redirect to HTTPS.

# HSTS header (add to your server response)
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Common Vulnerabilities

The OWASP Top 10 is the industry-standard list of the most critical web security risks. Let's look at the ones every backend developer must know.

SQL Injection

SQL injection happens when user input is directly concatenated into a SQL query. The attacker sends malicious SQL that the database executes as if it were part of the query.

-- VULNERABLE: User input directly in the query
-- If username = "admin' OR '1'='1" ...
SELECT * FROM users WHERE username = 'admin' OR '1'='1' AND password = '';
-- This returns ALL users! The attacker is now "logged in."

-- The attacker could also do:
-- username = "'; DROP TABLE users; --"
SELECT * FROM users WHERE username = ''; DROP TABLE users; --';

// VULNERABLE - string concatenation
const query = `SELECT * FROM users WHERE username = '${username}'`;

// SAFE - parameterized query (placeholder)
const query = 'SELECT * FROM users WHERE username = $1';
const result = await db.query(query, [username]);

XSS (Cross-Site Scripting)

XSS lets an attacker inject malicious JavaScript into your pages. When other users view the page, the script runs in their browser — stealing cookies, tokens, or redirecting them to phishing sites.

// VULNERABLE: Rendering user input as HTML
element.innerHTML = userComment;
// If userComment = ""
// The script executes in every visitor's browser!

// SAFE: Use textContent (escapes HTML)
element.textContent = userComment;

// SAFE: Server-side output encoding
// Most template engines auto-escape: {{ userComment }} in EJS, Jinja2, etc.

CSRF (Cross-Site Request Forgery)

CSRF tricks a logged-in user's browser into making a request they didn't intend. If you're logged into your bank and visit a malicious page, that page could submit a hidden form to transfer money — your browser sends your cookies automatically.

// CSRF attack: malicious page includes this hidden form
// 

//   
//   
// 
// 

// PREVENTION: Include a CSRF token in your forms
// Server generates a unique token per session
app.use((req, res, next) => {
  if (req.method === 'GET') {
    req.session.csrfToken = generateRandomToken();
  }
  next();
});

// Verify the token on POST/PUT/DELETE
app.post('/transfer', (req, res) => {
  if (req.body.csrfToken !== req.session.csrfToken) {
    return res.status(403).json({ error: 'CSRF token mismatch' });
  }
  // Process the legitimate request
});

CORS Misconfiguration

CORS (Cross-Origin Resource Sharing) is a browser security feature that blocks requests from a different domain unless the server explicitly allows it. Misconfiguring CORS can open your API to attacks.

// DANGEROUS - allows ANY origin
app.use(cors({ origin: '*', credentials: true }));
// This is a security hole! Any website can make requests to your API.

// SAFE - whitelist specific origins
const allowedOrigins = [
  'https://yourapp.com',
  'https://admin.yourapp.com'
];

app.use(cors({
  origin: (origin, callback) => {
    if (!origin || allowedOrigins.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error('Not allowed by CORS'));
    }
  },
  credentials: true  // Allow cookies
}));

Security Checklist

Keep this list handy when building or reviewing any backend system. If you check all 10 boxes, you're ahead of most developers.

• Hash passwords with bcrypt or Argon2 — never store plaintext, never use MD5/SHA alone.
• Use HTTPS everywhere — TLS in production is non-negotiable. Enable HSTS.
• Validate and sanitize ALL input — never trust the client. Validate on the server, even if the frontend also validates.
• Use parameterized queries — prevent SQL injection. Never concatenate user input into queries.
• Set secure cookie flags — HttpOnly, Secure, SameSite=Lax (or Strict).
• Implement rate limiting — prevent brute-force login attacks. Use libraries like express-rate-limit or API gateway limits.
• Keep dependencies updated — run npm audit or pip audit regularly. Outdated packages are the #1 attack vector.
• Use environment variables for secrets — never commit API keys, database passwords, or JWT secrets to version control.
• Set Content-Security-Policy headers — restrict what scripts, styles, and resources browsers can load.
• Log security events — track failed logins, permission changes, and suspicious activity. You can't fix what you can't see.