Express.js Authentication and Authorization: Protect Routes, Records, and Actions

Identity and Access

Authentication proves who the user is. Authorization decides what that user is allowed to do.

This distinction matters more in backend work than in frontend work because the backend is where the sensitive decision must actually be enforced.

Express makes auth flow very visible, which is helpful for learning and for debugging.

A backend is only as safe as its least careful permission check.

Login Is Only The First Layer

Beginners often feel done once they can issue a session or token, but a signed-in user is not automatically a trusted user for every route. Access rules often depend on workspace membership, ownership, role, plan level, or the record being touched.

This is why authorization deserves separate attention. The question is not only "is the user real?" but also "should this user be allowed to perform this exact operation on this exact resource?"

Authentication establishes identity.
Authorization enforces permission.
Both must be checked on the server side.

Middleware Helps, But Rules Must Stay Clear

Express middleware is a natural place to verify tokens or sessions and attach the authenticated user context. That is helpful, but it does not magically solve all permission questions. Some access decisions need to happen deeper, when the actual resource is known.

Professional teams often centralize important permission logic so it is not reimplemented differently across many controllers. Consistency matters because permission drift creates dangerous bugs.

Use middleware for shared identity checks.
Use deeper policy logic for record-specific or operation-specific permissions.
Keep permission rules understandable enough to review confidently.

Authenticate A User And Protect A Resource

Authentication proves identity. A browser application may use a server-side session cookie, while an API may use a bearer token. Passwords must be hashed with a modern password-hashing algorithm, login responses should not reveal whether an account exists, and sensitive endpoints need rate limiting and audit events.

After authentication, attach a minimal verified principal to the request: user ID, tenant ID, roles or token abilities, and authentication context. Never trust user or role fields submitted in the body or arbitrary headers. Middleware can reject missing or expired credentials before the controller runs.

Authorization decides whether that principal may perform one action on one resource. Load the requested invoice, order, or project and verify ownership, tenant, state, and permission. A valid token does not grant access to every record. Return 401 for missing or invalid identity and 403 for an authenticated principal without permission.

Hash passwords and protect login endpoints.
Build principals only from verified credentials.
Separate authentication from authorization.
Check permission against the loaded resource.
Use consistent 401, 403, and 404 behavior.

Think Like A Defensive Backend Engineer

A safe backend assumes clients can be wrong, stale, malicious, or simply out of sync. That means hidden buttons, disabled fields, and frontend-only route guards are never enough for protection.

Prefer server-side authorization checks for every sensitive read or write. Avoid relying on hidden buttons, client route guards, or a token that only proves identity without proving permission.

Protect reads as carefully as writes when the data is sensitive.
Design error responses that do not leak unnecessary detail.
Log important security-relevant actions for later review.

Separate Identity from Permission Checks

Authenticate a user, then authorize access to a specific invoice using role and ownership rules. Keep the authorization decision close to the resource lookup so object-level access cannot be skipped.

A valid token proves identity but not permission. Trusting a user ID supplied in the request body creates an insecure direct object reference when it differs from the authenticated subject.

Verification must use evidence that matches the concept. Test anonymous, expired-token, wrong-owner, allowed-owner, administrator, and deleted-resource cases with explicit 401, 403, and 404 behavior. Repeat the check after deliberately introducing the failure, then after the fix. The contrast between those runs is the part that turns a definition into practical understanding.

Sessions, Tokens, Revocation, And Multi-Tenant Safety

For cookie sessions, use Secure, HttpOnly, and appropriate SameSite settings, rotate the session identifier after login, protect state changes from CSRF, and store sessions in a shared backend for multiple instances. Revoke sessions after password changes or suspicious activity and bound both idle and absolute lifetime.

For tokens, validate issuer, audience, signature, expiry, and allowed algorithms. Keep access tokens short-lived and rotate refresh tokens with reuse detection. Token claims become stale when roles or account state change, so sensitive operations may need a fresh server-side permission check or token version.

Multi-tenant applications must scope the data query itself to the authenticated tenant, then apply action permission. This reduces accidental record disclosure and insecure direct object references. Log security-relevant events with request ID, actor, tenant, action, outcome, and resource identifier without recording passwords or raw tokens.

Harden and rotate session identifiers.
Validate every security-relevant token claim.
Support revocation and refresh-token reuse detection.
Scope resource queries by tenant.
Audit important access decisions safely.

Credential Lifecycle

Store passwords with a current adaptive password-hashing function and per-password salts through a maintained library; never encrypt them for later recovery. Rate-limit login using several signals, return a generic failure that does not confirm account existence, and rehash on successful login when policy parameters advance. Password reset tokens need strong randomness, short expiry, one-time use, and storage that does not expose the raw token after a database leak.

After login, create a new session identifier to prevent fixation. On password change, account recovery, privilege change, or suspicious activity, decide which sessions and refresh tokens are revoked. Logout is a server-side state transition for sessions or revocable tokens, not merely deleting a browser value. Record credential events without logging passwords, reset links, cookies, or bearer tokens.

Cookie and CSRF Boundary

HttpOnly reduces script access to a session cookie, Secure restricts transport to HTTPS, and SameSite influences cross-site sending. These flags do not authorize a request. Protect cookie-authenticated state changes with CSRF defenses and verify origin according to the application model. CORS controls which browsers expose cross-origin responses; it is not authentication and does not stop direct clients.

Token Verification

Configure an allow-list of expected algorithms and validate issuer, audience, expiry, and not-before semantics. Resolve keys from a trusted source with bounded caching and rotation behavior. A cryptographically valid token can still belong to a disabled account or carry stale authorization, so sensitive operations may need current server-side state and resource policy checks.

Authorization Race

If permission depends on mutable ownership, membership, or workflow status, perform the check close to the write and inside the same transaction or conditional database statement. Checking permission in middleware and writing much later can allow a concurrent revocation or transfer to be ignored. Audit both the actor and effective tenant at the durable change boundary.

A practical permission chain

This sequence is a good habit for protected API work.

A practical permission chain

Read token or session -> identify user -> load target resource -> verify role or ownership -> allow or deny -> log important sensitive operations

Permission depends on both user and target resource.
The same user may be allowed in one workspace but denied in another.
UI checks alone are never enough for backend safety.

Separate Identity from Permission Checks example

const invoice = await invoices.findById(req.params.id);
if (!invoice) return res.sendStatus(404);
if (invoice.ownerId !== req.user.id && req.user.role !== 'admin') {
  return res.sendStatus(403);
}

Authentication and object authorization middleware

Identity middleware verifies the token; the handler still checks the record.

Authentication and object authorization middleware

router.get(\"/invoices/:id\", authenticate, async (req, res) => {
  const invoice = await invoices.findOne({
    id: req.params.id,
    tenantId: req.user.tenantId
  });

  if (!invoice) return res.sendStatus(404);
  const allowed = invoice.ownerId === req.user.id
    || req.user.roles.includes(\"accounting\");
  if (!allowed) return res.sendStatus(403);

  res.json(invoice);
});

Tenant scoping happens in the query.
Do not accept ownerId as authorization evidence.
Apply field filtering before returning the model.

Secure session cookie settings

Cookie flags reduce exposure to script access and cross-site requests.

Secure session cookie settings

app.use(session({
  name: \"sid\",
  secret: config.sessionSecret,
  store: sessionStore,
  resave: false,
  saveUninitialized: false,
  cookie: {
    httpOnly: true,
    secure: true,
    sameSite: \"lax\",
    maxAge: 30 * 60 * 1000
  }
}));

Use CSRF protection for state-changing browser requests.
Regenerate the session after authentication.
Set proxy trust correctly before secure cookies behind a proxy.

Before you move on