Authentication Best Practices

Easy•

Authentication proves user identity and establishes a session or token lifecycle. Strong frontend answers explain how browser storage, cookies, XSS, CSRF, token expiration, and recovery flows affect the system.

Quick Navigation: Understanding Authentication Flow • Password Security • Session Management • Authentication Methods Comparison • Best Practices for Implementation

Quick Decision Guide

Senior Decision Guide:

Password hashing: Hash passwords on the server with slow salted algorithms such as Argon2id or bcrypt. Never store plaintext passwords.

Sessions: HttpOnly, Secure cookies reduce JavaScript token theft, but cookie-backed auth still needs SameSite and CSRF-aware design.

JWT / bearer tokens: JWTs are not automatically safer or more scalable. Their safety depends on lifetime, storage, revocation, rotation, and where validation happens.

OAuth/OIDC: Browser-based apps should use Authorization Code + PKCE. SPAs are public clients and cannot safely store client secrets.

Frontend responsibility: Client-side checks improve UX, but authentication and authorization enforcement must be server-side.

Interview signal: Explain the threat model: XSS, CSRF, token theft, session fixation, refresh failure, logout, and multi-tab behavior.

Understanding Authentication Flow

Overview of Authentication

Authentication verifies who a user is. Session management decides how the application remembers that identity across requests. Authorization decides what the authenticated user may do.

Figure 1: Authentication Flow

┌─────────────┐         ┌──────────────┐         ┌─────────────┐
│   User      │         │   Server     │         │   Database   │
│  Browser    │         │              │         │              │
└──────┬──────┘         └──────┬───────┘         └──────┬──────┘
       │                       │                        │
       │ 1. Submit Credentials │                        │
       │    (password, OAuth,  │                        │
       │     passkey, etc.)    │                        │
       ├───────────────────────>                        │
       │                       │                        │
       │                       │ 2. Look up identity / │
       │                       │    credential record  │
       │                       ├────────────────────────>
       │                       │                        │
       │                       │ <───────────────────────
       │                       │    User/Auth Record   │
       │                       │                        │
       │                       │ 3. Verify proof       │
       │                       │    of identity        │
       │                       │                        │
       │                       │ 4. Create session or  │
       │                       │    issue token        │
       │                       │                        │
       │ <───────────────────────                        │
       │    Session cookie /   │                        │
       │    token response     │                        │
       │                       │                        │
       │ 5. Browser carries    │                        │
       │    credential on      │                        │
       │    later requests     │                        │

Authentication Methods

1. Password-Based Authentication

•Username/email + password

•Requires slow salted password hashing on the server

•Needs rate limiting, reset flows, and common-password checks

2. Session-Based Authentication

•Server stores session state

•Browser usually holds an opaque session ID in an HttpOnly cookie

•Easier server-side revocation, but cookie flows need CSRF-aware design

3. Token-Based Authentication (JWT / Bearer Tokens)

•Token is sent with API requests

•JWT payloads are readable unless encrypted; signatures prevent tampering, not reading

•Lifetime, storage, rotation, and revocation determine safety

4. OAuth 2.0 + OIDC

•OAuth handles delegated authorization

•OIDC adds identity

•Modern browser apps should use Authorization Code + PKCE

5. MFA / Passkeys

•Adds stronger proof beyond passwords

•Reduces account takeover and phishing risk

•Recovery UX becomes part of the security design

Password Security

Never Store Plain Text Passwords

Figure 2: Password Storage Comparison

┌─────────────────────────────────────────────────────────┐
│              Password Storage Methods                    │
├─────────────────────────────────────────────────────────┤
│                                                          │
│  ❌ Plain Text                                           │
│  Stored: "mypassword123"                                │
│  Risk: Immediate compromise if database leaks            │
│                                                          │
│  ❌ Fast Hash Only                                       │
│  Stored: SHA256(password)                                │
│  Risk: Cheap offline guessing at high speed              │
│                                                          │
│  ✅ Slow Salted Password Hash                            │
│  Stored: Argon2id/bcrypt/scrypt(password, salt, cost)    │
│  Benefit: Unique per password and expensive to guess     │
│                                                          │
└─────────────────────────────────────────────────────────┘

Password Hashing Process

Figure 3: Password Hashing Flow

┌─────────────┐         ┌──────────────┐         ┌─────────────┐
│   User      │         │   Server     │         │   Database   │
│ Registration│         │              │         │              │
└──────┬──────┘         └──────┬───────┘         └──────┬──────┘
       │                       │                        │
       │ 1. Submit Password    │                        │
       ├───────────────────────>                        │
       │                       │                        │
       │                       │ 2. Generate salt      │
       │                       │    and choose cost    │
       │                       │                        │
       │                       │ 3. Hash with          │
       │                       │    password hasher    │
       │                       │                        │
       │                       │ 4. Store hash params  │
       │                       │    + salt + hash      │
       │                       ├────────────────────────>
       │                       │                        │
       │ <───────────────────────                        │
       │    Success            │                        │

Use Password Hashing Algorithms

•Argon2id: strong modern default when available

•bcrypt: widely supported adaptive hashing

•scrypt: memory-hard alternative

Avoid fast general-purpose hashes such as raw SHA-256 for password storage.

Password Policy

•Prefer longer passwords/passphrases over rigid complexity theater

•Check against common or breached password lists

•Rate limit login and reset flows

•Avoid predictable rules that force users into patterns like "Password1!"

•Design password reset as carefully as login

Session Management

Session vs Token-Based Authentication

Figure 4: Session-Based Authentication Flow

┌─────────────┐         ┌──────────────┐         ┌─────────────┐
│   User      │         │   Server     │         │   Session   │
│  Browser    │         │              │         │   Store     │
└──────┬──────┘         └──────┬───────┘         └──────┬──────┘
       │                       │                        │
       │ 1. Login              │                        │
       ├───────────────────────>                        │
       │                       │                        │
       │                       │ 2. Create session     │
       │                       ├────────────────────────>
       │                       │                        │
       │                       │ <───────────────────────
       │                       │    Session ID          │
       │                       │                        │
       │ <───────────────────────                        │
       │    HttpOnly cookie    │                        │
       │    with session ID    │                        │
       │                       │                        │
       │ 3. Request with       │                        │
       │    cookie             │                        │
       ├───────────────────────>                        │
       │                       │                        │
       │                       │ 4. Validate session   │
       │                       ├────────────────────────>
       │                       │                        │
       │                       │ <───────────────────────
       │                       │    Session data        │
       │                       │                        │
       │ <───────────────────────                        │
       │    Response           │                        │

Figure 5: Token-Based Authentication Flow (JWT / Bearer Token)

┌─────────────┐         ┌──────────────┐
│   User      │         │   Server     │
│  Browser    │         │              │
└──────┬──────┘         └──────┬───────┘
       │                       │
       │ 1. Login              │
       ├───────────────────────>
       │                       │
       │                       │ 2. Issue signed token │
       │                       │    or bearer token    │
       │                       │
       │ <───────────────────────
       │    Access token       │
       │                       │
       │ 3. Store according    │
       │    to threat model    │
       │                       │
       │ 4. Request with       │
       │    Authorization      │
       │    header/cookie      │
       ├───────────────────────>
       │                       │
       │                       │ 5. Validate token     │
       │                       │    and permissions    │
       │                       │
       │ <───────────────────────
       │    Response           │

Aspect	Server-Side Sessions	Token-Based / JWT
Server state	Session data stored server-side	May validate locally, but revocation/rotation may still need server state
Browser storage	Usually opaque ID in HttpOnly cookie	Header token, cookie, or memory depending on architecture
Revocation	Straightforward: delete server session	Needs short lifetimes, rotation, blocklist, introspection, or server-side session layer
XSS risk	HttpOnly cookie cannot be read by JS, but app can still be abused if XSS exists	Browser-readable tokens are stealable via XSS; memory storage reduces persistence but complicates reloads
CSRF risk	Cookie-backed auth needs SameSite/token/origin strategy	Authorization header tokens reduce classic CSRF but shift attention to XSS/storage
Best fit	Web apps, BFF architectures, strong server control	APIs, mobile clients, distributed systems, cross-service authorization

res.cookie('session', sessionId, {
  httpOnly: true,
  secure: process.env.NODE_ENV === 'production',
  sameSite: 'lax', // choose Strict/Lax/None based on product flow
  maxAge: 24 * 60 * 60 * 1000 // 24 hours
});

Senior Nuance

Do not say "sessions are secure and JWTs are insecure" or the reverse. The real question is where the credential lives, how long it lasts, how it is revoked, and which attack class is most important for the product.

Authentication Methods Comparison

Method	What it solves	Trade-offs
Passwords	First-party identity proof	Requires hashing, reset flow, rate limits, breach checks
Sessions	Server-controlled continuity	Needs shared storage and CSRF-aware cookies
JWT / bearer tokens	Portable API credentials	Token theft and revocation must be designed carefully
OAuth 2.0	Delegated authorization	More moving parts; must validate state and redirect flows
OIDC	Identity on top of OAuth	ID token validation and provider trust matter
MFA / Passkeys	Stronger account protection	Recovery and device support are product concerns

Best Practices for Implementation

Security Checklist

Password Security:

•Hash passwords with Argon2id, bcrypt, or scrypt

•Never store plaintext passwords

•Check common or breached password lists

•Rate limit login and reset flows

•Design password reset as carefully as login

Session / Token Handling:

•Prefer HttpOnly cookies for browser sessions when appropriate

•Use Secure cookies in production

•Choose SameSite based on actual cross-site flow needs

•Regenerate session IDs after login

•Expire and revoke sessions intentionally

•Avoid putting tokens in URLs

JWT / Bearer Token Safety:

•Keep lifetimes short when tokens are browser-exposed

•Plan refresh, rotation, logout, and revocation

•Do not put sensitive secrets in readable JWT payloads

•Treat localStorage token storage as high XSS blast radius

OAuth / OIDC:

•Use Authorization Code + PKCE for browser apps

•Validate state and nonce where applicable

•Do not store client secrets in the browser

•Handle provider outage and refresh failure cleanly

Frontend Responsibility:

•Client checks are for UX only

•Server must enforce authentication and authorization

•Distinguish unauthenticated, unauthorized, expired, and degraded identity states

Key Takeaways

1Authentication verifies identity; authorization controls allowed actions.

2Sessions and JWTs have different lifecycle and storage trade-offs.

3HttpOnly cookies reduce XSS token theft but require CSRF-aware design.

4JWTs are not automatically safer or better; revocation and storage matter.

5Authorization Code + PKCE is the modern OAuth baseline for browser apps.

6Frontend auth UX should handle expiration, logout, recovery, and degraded identity providers.