What is the difference between authentication and authorization?

Authentication verifies who a user is (login). Authorization decides what that user can do (permissions). You authenticate first, then authorize each protected action.

Should I use sessions or JWTs?

Use sessions when you need immediate server-side logout and you run a traditional web app with cookies. Use JWTs for APIs, mobile clients, or distributed services where you want stateless verification. Many production apps combine short-lived JWTs with refresh tokens or use sessions behind a BFF layer.

Can I store sessions in Render Key Value?

Yes. Render Key Value is Redis-compatible and works with connect-redis 8+ for shared session storage across web service instances. Use the same instance with rate-limit-redis once you run more than one web service instance, so login attempt counters stay consistent. Set REDIS_URL to your Key Value internal connection string. See Render Key Value.

Why are my secure session cookies missing on Render?

Render terminates TLS at the load balancer, so Express sees plain HTTP. With cookie: { secure: true }, express-session will not set the cookie unless you call app.set('trust proxy', 1) so Express trusts X-Forwarded-Proto. Without that setting, every login can fail silently.

Does Render provide HTTPS for auth endpoints?

Yes. Render terminates TLS on all public web services and provisions managed certificates automatically. See Fully managed TLS certificates.

How do I revoke a JWT before it expires?

JWTs are stateless by default. To revoke early, keep access tokens short-lived, rotate refresh tokens, or maintain a server-side denylist of token IDs until they expire.

Is sameSite: 'strict' enough for CSRF protection?

It helps by limiting when browsers send session cookies on cross-site requests, but it is not a complete CSRF defense on its own. Use CSRF tokens or equivalent protections on state-changing routes that rely on cookies.

When should I use RBAC vs resource-based authorization?

Use RBAC when permissions map cleanly to roles such as admin or editor. Add resource-based checks when users should only access records they own, even if they share the same role.

Platform

How to implement authentication and authorization

July 08, 2026

Authentication and authorization form the security foundation of web applications, yet they serve distinct purposes. Authentication verifies identity: answering “who are you?” through credentials like passwords or tokens. Authorization determines permissions: answering “what can you do?” based on roles or attributes. This guide teaches authentication patterns through simplified examples. You’ll learn to evaluate session-based, token-based, and third-party authentication strategies, understand their trade-offs, and implement authorization patterns that scale with your application’s complexity.

Before implementing authentication, ensure you have:

A web application with user registration and login endpoints
Database access for storing user credentials and session data
HTTPS configured (Render provides fully managed TLS certificates for all public web services)
Environment variable management for secrets

Dependency versions referenced:

Node.js 20+ with Express 4.18+ or Express 5
express-session 1.17+ and connect-redis 8+ (named RedisStore import; v7 used a default export)
express-rate-limit 7+ with rate-limit-redis 4+ when you scale past one instance
Render Key Value (Redis-compatible) for distributed session storage and shared rate-limit counters
jsonwebtoken 9+

Install session dependencies:

bash

npm install express-session connect-redis@^8 redis

Install the authentication and rate-limiting dependencies used later in this guide:

bash

npm install jsonwebtoken bcrypt express-rate-limit rate-limit-redis

Session-based authentication stores authentication state on your server, typically in a Redis-compatible store like Render Key Value or a database. After successful login, your server creates a session and returns a session ID via HTTP cookie. This approach suits traditional web applications and simplifies token management since you can invalidate sessions server-side immediately. However, it requires persistent session storage accessible to all your application instances.

Token-based authentication shifts state to the client through signed tokens, typically JWTs (JSON Web Tokens). After login, your server generates a cryptographically signed token containing user claims. Your server validates tokens without querying a database on each request. This stateless approach excels in distributed systems and APIs where session synchronization creates complexity. The trade-off: you cannot invalidate access tokens before expiration without additional infrastructure such as a token blocklist or short-lived tokens with refresh rotation.

Third-party authentication delegates identity verification to specialized providers: OAuth2 flows (Google, GitHub) or managed services (Auth0, WorkOS). This reduces your security burden but introduces external dependencies.

Session authentication follows this flow: your user submits credentials, your server validates against stored hashes, creates a session with unique identifier, stores session data in your session store, and returns the session ID via secure, httpOnly cookie.

jsx

// Node.js/Express session creation
app.post('/login', async (req, res) => {
  const { email, password } = req.body;

  const user = await db.findUserByEmail(email);
  if (!user || !(await bcrypt.compare(password, user.passwordHash))) {
    return res.status(401).json({ error: 'Invalid credentials' });
  }

  // Regenerate to prevent session fixation: do not reuse a pre-login session ID
  req.session.regenerate((err) => {
    if (err) return res.status(500).json({ error: 'Session error' });
    req.session.userId = user.id;
    req.session.role = user.role;
    res.json({ success: true });
  });
});

Logout destroys the server-side session immediately (one of the main advantages of sessions over JWTs):

jsx

app.post('/logout', (req, res) => {
  req.session.destroy(() => res.json({ success: true }));
});

Session validation middleware:

javascript

function requireAuth(req, res, next) {
  if (!req.session.userId) {
    return res.status(401).json({ error: 'Authentication required' });
  }

  req.user = { id: req.session.userId, role: req.session.role };
  next();
}

app.get('/dashboard', requireAuth, (req, res) => {
  res.json({ message: `Welcome user ${req.user.id}` });
});

Configure express-session with Render Key Value for distributed systems:

javascript

const session = require('express-session');
const { RedisStore } = require('connect-redis'); // connect-redis 8+
const { createClient } = require('redis');

const redisClient = createClient({
  url: process.env.REDIS_URL
});
redisClient.connect().catch(console.error);

// Render's load balancer terminates TLS, so tell Express to trust the
// X-Forwarded-Proto header; without this, secure: true cookies are never set.
app.set('trust proxy', 1);

app.use(session({
  store: new RedisStore({ client: redisClient }),
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: {
    secure: true, // HTTPS only (requires trust proxy behind Render)
    httpOnly: true,
    sameSite: 'strict',
    maxAge: 24 * 60 * 60 * 1000 // 24 hours
  }
}));

Point REDIS_URL at your Render Key Value connection string when deploying on Render.

Token authentication eliminates server-side session storage by encoding authentication state into cryptographically signed tokens. Your server validates token signatures and expiration, extracting user information from claims without database queries.

javascript

const jwt = require('jsonwebtoken');

function generateToken(user) {
  const payload = {
    userId: user.id,
    role: user.role,
  };

  return jwt.sign(payload, process.env.JWT_SECRET, {
    expiresIn: '1h',
    issuer: 'your-app-name',
    audience: 'your-api'
  });
}

app.post('/login', async (req, res) => {
  const user = await validateCredentials(req.body);
  const token = generateToken(user);
  res.json({ token });
});

Token validation middleware:

javascript

function verifyToken(req, res, next) {
  const authHeader = req.headers.authorization;
  if (!authHeader?.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'Token required' });
  }

  const token = authHeader.substring(7);
  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET, {
      issuer: 'your-app-name',
      audience: 'your-api'
    });

    req.user = decoded;
    next();
  } catch (err) {
    if (err.name === 'TokenExpiredError') {
      return res.status(401).json({
        error: 'token_expired',
        message: 'Token has expired, please refresh'
      });
    }
    return res.status(401).json({ error: 'Invalid token' });
  }
}

JWT signatures prevent tampering but do not encrypt payload data. Never store sensitive information in tokens. Implement refresh tokens for long-lived sessions: access tokens expire quickly (15 minutes to 1 hour), while refresh tokens last longer and obtain new access tokens.

Authorization determines what your authenticated users can access. Start with patterns that match your current needs and evolve as your requirements grow.

Role-Based Access Control (RBAC) assigns users to roles with predefined permissions:

javascript

function requireRole(...allowedRoles) {
  return (req, res, next) => {
    if (!allowedRoles.includes(req.user.role)) {
      return res.status(403).json({
        error: 'insufficient_permissions',
        required: allowedRoles
      });
    }
    next();
  };
}

app.delete('/users/:id', requireAuth, requireRole('admin'), deleteUser);
app.put('/posts/:id', requireAuth, requireRole('admin', 'editor'), updatePost);

Resource-based authorization checks ownership or relationships:

javascript

async function requireOwnership(req, res, next) {
  const resourceId = req.params.id;
  const resource = await db.findResource(resourceId);

  if (!resource || resource.ownerId !== req.user.userId) {
    return res.status(403).json({ error: 'Access denied' });
  }

  req.resource = resource;
  next();
}

Chain authorization middlewares for complex policies:

javascript

app.put('/documents/:id',
  requireAuth,
  requireRole('editor', 'admin'),
  requireOwnership,
  updateDocument
);

Implement multiple security layers for robust protection:

Password hashing with bcrypt:

javascript

const bcrypt = require('bcrypt');

async function hashPassword(password) {
  return bcrypt.hash(password, 12); // Cost factor 12
}

async function verifyPassword(password, hash) {
  return bcrypt.compare(password, hash);
}

Rate limiting prevents brute-force attacks. express-rate-limit counts in memory by default, so each instance has its own counter. With two instances an attacker gets twice the attempts, and autoscaling makes that worse: the same reason you put sessions in Key Value applies to rate limits. Share counters with rate-limit-redis on the same Key Value instance:

javascript

const rateLimit = require('express-rate-limit');
// Aliased to avoid colliding with connect-redis's RedisStore export
const { RedisStore: RateLimitRedisStore } = require('rate-limit-redis');

const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  limit: 5, // v7 renamed `max` to `limit` (`max` still works); 5 attempts per window across all instances
  message: 'Too many login attempts, try again later',
  store: new RateLimitRedisStore({
    sendCommand: (...args) => redisClient.sendCommand(args),
    prefix: 'rl:login:'
  })
});

app.post('/login', loginLimiter, handleLogin);

Reuse the same redisClient you configured for sessions. On a single instance, the in-memory default is fine for local development; switch to a shared store before you scale.

CSRF protection for session-based authentication:

javascript

// Issue a CSRF token per session for state-changing form posts
app.get('/form', requireAuth, (req, res) => {
  const csrfToken = generateCsrfToken(req.session.id);
  res.render('form', { csrfToken });
});

app.post('/form', requireAuth, validateCsrfToken, handleFormSubmission);

The generateCsrfToken and validateCsrfToken helpers above are placeholders. The once-standard csurf middleware is no longer maintained, so use a maintained library such as csrf-csrf or implement the double-submit-cookie pattern yourself.

Configure secure session cookies with secure: true (HTTPS-only), httpOnly: true (JavaScript cannot access), and sameSite: 'strict' (limits cross-site cookie submission). Pair strict cookies with CSRF tokens on mutating routes.

To build production systems:

Implement password reset flows with time-limited, single-use tokens
Add audit logging for authentication events and security monitoring
Test token expiration and refresh flows for seamless user experience
Configure monitoring for authentication failures and unusual access patterns
Review security headers: implement Content-Security-Policy and protective headers

Authentication complexity scales with your application’s requirements. Start with patterns matching your current needs and evolve your architecture as your security demands grow.

How to implement authentication and authorization

Prerequisites

Authentication strategies overview

Session-based authentication pattern

Token-based authentication pattern

Authorization patterns

Security implementation

Next steps

Frequently asked questions