Production-Ready Authentication Patterns for Modern SaaS

JWT vs. Session-Based Authentication

The choice between JWT and session-based authentication isn't just about preference—it's about your architecture. JWTs are stateless, making them ideal for microservices and distributed systems. Sessions require server-side storage but offer better revocation control.

For most SaaS applications, we recommend JWTs with short expiration times (15 minutes) and refresh tokens stored securely in HTTP-only cookies. This gives you the benefits of statelessness while maintaining security through token rotation.

// JWT token structure
{
  "userId": "user_123",
  "email": "user@example.com",
  "role": "user",
  "iat": 1638360000,
  "exp": 1638360900  // 15 minutes
}

// Refresh token (stored in HTTP-only cookie)
{
  "userId": "user_123",
  "tokenId": "refresh_abc123",
  "exp": 1638446400  // 24 hours
}

Password Reset Flow

A secure password reset flow requires multiple safeguards. Never expose user existence, use time-limited tokens, and implement rate limiting. Here's our production pattern:

1. User requests reset: Always return the same message whether the email exists or not. This prevents email enumeration attacks.
2. Generate secure token: Use crypto.randomBytes(32) to create a 256-bit token. Store it hashed in the database with an expiration (typically 1 hour).
3. Send reset email: Include the token in a secure link. Never include it in the URL path—use query parameters that are logged.
4. Validate and reset: Check token expiration, verify the hash, then allow password change. Immediately invalidate the token after use.

// Password reset token generation
import crypto from 'crypto';

const resetToken = crypto.randomBytes(32).toString('hex');
const hashedToken = crypto
  .createHash('sha256')
  .update(resetToken)
  .digest('hex');

// Store in database with expiration
await db.passwordResets.create({
  userId: user.id,
  token: hashedToken,
  expiresAt: new Date(Date.now() + 3600000) // 1 hour
});

Email Verification

Email verification prevents fake accounts and ensures you have valid contact information. The pattern is similar to password reset but with different security considerations.

Key differences: verification tokens can be longer-lived (24-48 hours), and you should allow re-sending verification emails. Track verification attempts to prevent abuse.

Social Login Integration

OAuth 2.0 is the standard for social login, but implementation details matter. Use Passport.js or similar libraries, but understand what they're doing under the hood. Always verify the ID token server-side, never trust client-side claims.

When a user signs in with Google, GitHub, or another provider, create a linked account record. This allows users to connect multiple providers to the same account, improving UX while maintaining security.

Multi-Factor Authentication (MFA)

MFA adds an extra layer of security by requiring a second factor. TOTP (Time-based One-Time Password) apps like Google Authenticator are the most common. SMS-based 2FA is less secure but more accessible.

Implementation requires generating a secret, displaying a QR code, and verifying codes on login. Store backup codes securely and allow users to regenerate them. Our templates include MFA-ready patterns that you can enable when needed.