How do you handle authentication properly?

Authentication is one of those foundational topics that every developer encounters early on, but handling it properly goes way beyond just checking usernames and passwords. It’s about securing user identities, managing sessions, and ensuring that the system remains safe and scalable as it grows. Over the years, I’ve seen plenty of projects where authentication was either an afterthought or implemented in a way that caused headaches down the line—whether that’s security vulnerabilities, poor user experience, or maintainability nightmares.

Let me walk you through how I approach authentication in real-world applications, including the core concepts, practical tips, common pitfalls, and how to balance security with usability and performance.

Core Concepts of Authentication

At its heart, authentication is about verifying that a user is who they claim to be. This usually involves:

• Credentials: Something the user knows (password), has (a device or token), or is (biometrics).
• Verification: The server checks these credentials against a trusted source.
• Session Management: Once verified, the server needs to remember the user’s identity for subsequent requests.

Authentication is often confused with authorization, but they’re distinct. Authentication confirms identity, while authorization determines what that identity can do.

Common Authentication Methods

• Username and Password: The classic approach. Still most common but requires careful handling.
• Token-Based Authentication: Using JWTs (JSON Web Tokens) or opaque tokens for stateless sessions.
• OAuth / OpenID Connect: Delegated authentication, often via third-party providers like Google or Facebook.
• Multi-Factor Authentication (MFA): Adds an extra layer beyond just passwords.

Practical Authentication Flow

Here’s a typical flow I use when implementing authentication for a web app:

1. User submits credentials (usually username/email + password) over HTTPS.
2. Server validates credentials against a secure user store (database with hashed passwords).
3. If valid, server generates a session token or JWT and sends it back to the client.
4. Client stores the token securely (HTTP-only cookies or secure storage).
5. Subsequent requests include the token for authentication.
6. Server verifies the token, extracts user info, and authorizes access.

Example: Password Hashing

One of the most common mistakes I see is storing passwords in plain text or using weak hashing algorithms. Instead, always use a strong, adaptive hashing function like bcrypt, Argon2, or scrypt. These are designed to be slow and resistant to brute-force attacks.

const bcrypt = require('bcrypt');

async function hashPassword(plainPassword) {
  const saltRounds = 12; // balance between security and performance
  const hashed = await bcrypt.hash(plainPassword, saltRounds);
  return hashed;
}

async function verifyPassword(plainPassword, hashedPassword) {
  return await bcrypt.compare(plainPassword, hashedPassword);
}

Using a salt (which bcrypt does internally) ensures that even if two users have the same password, their hashes will be different. This protects against rainbow table attacks.

Session Management: Cookies vs Tokens

Once a user is authenticated, you need to maintain their session. There are two main approaches:

Approach	How It Works	Pros	Cons	Best Use Cases
Server-Side Sessions (Cookies)	Server stores session data; client holds a session ID in a cookie.	Easy to revoke sessions Less exposure to token theft Works well with traditional web apps	Scalability challenges (need shared session store) Requires CSRF protection	Monolithic apps, server-rendered pages
Token-Based (JWT)	Server issues signed token; client stores and sends it with each request.	Stateless, easy to scale Works well for APIs and SPAs Can include user claims	Harder to revoke tokens Token size can be large Must protect against token theft	APIs, mobile apps, microservices

In my experience, if you’re building a traditional web app with server-rendered pages, server-side sessions with HTTP-only cookies are simpler and more secure. For APIs or SPAs, JWTs are popular, but you need to be careful about token expiration and revocation.

Common Mistakes with JWTs

• Using JWTs as the sole source of truth without a revocation strategy. Once issued, JWTs are valid until they expire, which can be a security risk if a token is compromised.
• Storing JWTs in localStorage, which is vulnerable to XSS attacks. HTTP-only cookies are safer.
• Not validating the token signature properly or ignoring token expiration.

Security Considerations

Authentication is a prime target for attackers, so security must be baked in from the start:

• Always use HTTPS: Never send credentials or tokens over plain HTTP.
• Protect against brute force: Implement rate limiting and account lockouts after repeated failed attempts.
• Use strong password policies: Encourage users to create complex passwords, but avoid overly strict rules that frustrate users.
• Implement Multi-Factor Authentication (MFA): Adds a critical extra layer of security, especially for sensitive apps.
• Secure cookies: Use HTTP-only, Secure, and SameSite flags to prevent CSRF and XSS attacks.
• Session expiration: Sessions or tokens should expire reasonably quickly to limit risk if compromised.
• Logging and monitoring: Track authentication attempts and alert on suspicious activity.

Performance and Scalability

Authentication can become a bottleneck if not designed properly. Here’s what I keep in mind:

• Session store: If using server-side sessions, use a fast, distributed cache like Redis to handle session data across multiple servers.
• Token size: Keep JWT payloads minimal to reduce overhead on every request.
• Database queries: Avoid querying the user database on every request by embedding necessary claims in tokens or caching user info.
• Load balancing: Ensure session affinity or shared session stores to prevent users from losing sessions.

Common Pitfalls and How to Avoid Them

• Storing passwords in plain text: This is a critical security flaw. Always hash and salt passwords.
• Ignoring token expiration: Long-lived tokens increase risk. Use refresh tokens or short-lived access tokens.
• Not validating inputs: Always sanitize and validate login inputs to prevent injection attacks.
• Confusing authentication and authorization: Don’t mix these concerns; keep your code modular.
• Overcomplicating the flow: Sometimes developers build overly complex custom auth systems instead of using battle-tested libraries or services.

Interview Tips: How to Talk About Authentication

When discussing authentication in an interview, focus on:

• Security-first mindset: Explain how you protect user data and prevent common attacks.
• Trade-offs: Show awareness of pros and cons between session-based and token-based auth.
• Real-world experience: Share examples of how you handled authentication in production, including challenges and solutions.
• Best practices: Mention password hashing, HTTPS, MFA, and secure cookie flags.
• Scalability: Talk about how you designed auth to work in distributed environments.

Production Scenario: Migrating from Passwords to OAuth

In one project, we started with a simple username/password system but wanted to improve user onboarding by supporting social logins via OAuth providers like Google and Facebook. Here’s what we did:

• Added OAuth as an alternative login method, linking OAuth accounts to existing user profiles.
• Handled token exchange securely on the backend, never exposing client secrets.
• Maintained sessions via HTTP-only cookies for consistency.
• Implemented fallback password reset flows for users who registered with passwords.
• Ensured logging and monitoring for both auth methods.

This approach improved user experience and reduced friction while keeping security tight.

Comparison: Custom Authentication vs Using Third-Party Services

Aspect	Custom Authentication	Third-Party Services (Auth0, Firebase Auth)
Control	Full control over logic and data	Limited control, depends on provider
Development Speed	Slower, requires building and maintaining	Faster, ready-made solutions
Security	Depends on your implementation quality	Generally strong, maintained by experts
Customization	Highly customizable	Customizable but within provider limits
Cost	Infrastructure and maintenance costs	Pricing based on usage, can get expensive

For many startups or small teams, third-party auth services can save time and reduce risk. For large-scale or highly regulated apps, custom auth might be necessary.