Implementing Authentication and Authorization in Node.js Applications

Authentication answers the question "Who are you?" while authorization answers "What are you allowed to do?" In Node.js applications, these are two distinct layers that must be implemented separately. A user might successfully authenticate (prove their identity with a password) but still be denied access to an admin dashboard because their role does not include the required permissions. Conflating these two concepts is one of the most common security mistakes in backend development, leading to either overly permissive systems or broken access controls.

Passport.js is the de facto authentication middleware for Node.js, supporting over 500 authentication strategies. The Local Strategy handles traditional username/password login. Install `passport` and `passport-local`, then configure a strategy that queries your database with `User.findOne({ email })` and verifies the password using `bcrypt.compare()`. On successful authentication, Passport serializes the user into the session via `passport.serializeUser()`. Protect routes with `passport.authenticate('local')` middleware. Always hash passwords using `bcrypt` with a salt factor of 12+ before storing them in the database.

For modern API-first architectures, JWT-based authentication eliminates server-side session storage entirely. After successful login, the server generates a token using `jwt.sign({ userId, role }, process.env.JWT_SECRET, { expiresIn: '1h' })`. The client stores this token (typically in an HttpOnly cookie or memory—never localStorage for sensitive tokens) and includes it in the `Authorization: Bearer ` header on subsequent requests. Server middleware verifies the token with `jwt.verify()`, extracting the user payload without any database lookup. This stateless model scales horizontally across multiple server instances effortlessly.

Short-lived access tokens (15 minutes) combined with longer-lived refresh tokens (7–30 days) provide the best balance of security and usability. When the access token expires, the client sends the refresh token to a dedicated `/auth/refresh` endpoint. The server verifies the refresh token, invalidates it (one-time use), generates a new access-refresh token pair, and returns both. This refresh token rotation pattern ensures that if a refresh token is ever stolen, it can only be used once before being invalidated, limiting the attack window. Store refresh tokens in the database with a family identifier to detect token reuse attacks.

OAuth 2.0 allows users to authenticate using their existing accounts on trusted providers. Using `passport-google-oauth20`, configure the strategy with your Google Client ID, Client Secret, and callback URL. The flow works as follows: user clicks "Login with Google" → redirect to Google's consent screen → Google redirects back to your callback URL with an authorization code → your server exchanges the code for an access token → your server calls Google's API to get the user's profile → `User.findOrCreate()` links the Google profile to your local user record. This same pattern applies to GitHub, Microsoft, Facebook, and any OIDC-compliant provider.

RBAC assigns permissions to roles, and roles to users. Define a permissions map: `{ admin: ['users:read', 'users:write', 'posts:delete'], editor: ['posts:read', 'posts:write'], viewer: ['posts:read'] }`. Create a reusable middleware factory: `const authorize = (permission) => (req, res, next) => { if (!req.user) return res.status(401).json({ error: 'Unauthenticated' }); if (!permissions[req.user.role]?.includes(permission)) return res.status(403).json({ error: 'Forbidden' }); next(); }`. Apply it to routes: `router.delete('/posts/:id', authorize('posts:delete'), deletePost)`. This pattern scales cleanly as your application's permission model grows.

Authentication endpoints are prime targets for brute-force attacks. Use `express-rate-limit` to cap login attempts to 5 per 15-minute window per IP. Configure CORS with `cors({ origin: 'https://yourfrontend.com', credentials: true })` to restrict cookie-based authentication to your own domains. Add `helmet()` middleware to set security headers including `X-Content-Type-Options`, `Strict-Transport-Security`, and `X-Frame-Options`. For JWTs, never store secrets in code—use environment variables. Consider using RS256 (asymmetric) signing for JWTs in microservice architectures where multiple services need to verify tokens without sharing a secret.

Authentication logic must be thoroughly tested. Use Supertest with Jest to write integration tests that exercise the full HTTP flow. Test the happy path (valid credentials return a 200 and a token), invalid credentials (return 401), expired tokens (return 403), insufficient permissions (return 403), and rate-limited requests (return 429). Create a test helper that logs in a test user and returns the token for use in subsequent authenticated requests. Mock external OAuth providers using `nock` to intercept HTTP calls to Google/GitHub during CI pipeline runs. Ensure your test database is seeded with users of different roles to validate the RBAC middleware.