Why authorization differs from authentication in Express - Performance Evidence

Performance: Why authorization differs from authentication

MEDIUM IMPACT

This concept affects how quickly and securely a web app verifies user identity and grants access, impacting user interaction speed and security response.

Handling user access control in an Express app

Express

const authenticate = (req, res, next) => {
  // Verify user identity once and cache
  if (!req.user) {
    return res.status(401).send('Not authenticated');
  }
  next();
};

const authorize = (role) => (req, res, next) => {
  // Check user role separately
  if (req.user.role !== role) {
    return res.status(403).send('Not authorized');
  }
  next();
};

app.use(authenticate);
app.use('/admin', authorize('admin'));

Separates authentication and authorization, caches user info, and checks roles only when needed, reducing redundant checks and speeding up responses.

📈 Performance GainReduces database calls per request, lowers server load, and improves INP by faster permission checks.

Handling user access control in an Express app

Express

app.use((req, res, next) => {
  // Check user role on every request without caching
  if (!req.user) {
    return res.status(401).send('Not authenticated');
  }
  if (req.user.role !== 'admin') {
    return res.status(403).send('Not authorized');
  }
  next();
});

This pattern mixes authentication and authorization checks on every request without caching, causing repeated database calls and slowing response time.

📉 Performance CostTriggers multiple database lookups per request, increasing server response time and INP.

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Mixed auth checks on every request	N/A (server-side)	N/A	N/A	[X] Bad
Separate auth and role checks with caching	N/A (server-side)	N/A	N/A	[OK] Good

Rendering Pipeline

Authentication and authorization happen before rendering content, affecting how quickly the server responds and the browser can paint the page.

→Server Processing

→Network Response

→Browser Rendering

⚠️ BottleneckServer Processing due to repeated identity and permission checks

Core Web Vital Affected

INP

This concept affects how quickly and securely a web app verifies user identity and grants access, impacting user interaction speed and security response.

Optimization Tips

1Separate authentication (who you are) from authorization (what you can do).

2Cache authentication results to avoid repeated identity checks.

3Perform authorization checks only when necessary to reduce server load.

Performance Quiz - 3 Questions

What is the main difference between authentication and authorization in terms of performance?

A Authorization verifies identity; authentication checks permissions, so combining them speeds up requests.

B Both are the same and have no impact on performance.

C Authentication verifies identity; authorization checks permissions, so separating them reduces redundant checks.

D Authentication and authorization only affect client-side rendering speed.

DevTools: Network

How to check: Open DevTools, go to Network tab, observe response times for authenticated routes, and check if repeated calls delay responses.

What to look for: Look for long server response times or repeated authentication calls indicating inefficient checks.

Practice

1. In Express apps, what is the main difference between authentication and authorization?

easy

A. Authentication checks what the user can access; authorization verifies who they are.

B. Authentication verifies who the user is; authorization checks what they can access.

C. Authentication and authorization both check user identity only.

D. Authorization is done before authentication in Express.

Solution

1. Step 1: Understand authentication purpose

   Authentication confirms the user's identity, like logging in.

2. Step 2: Understand authorization purpose

   Authorization decides what resources or actions the authenticated user can access.

3. Final Answer:

   Authentication verifies who the user is; authorization checks what they can access. -> Option B

4. Quick Check:

   Authentication = identity, Authorization = permissions [OK]

Hint: Authentication = who, Authorization = what they can do [OK]

Common Mistakes:

• Confusing authentication with authorization
• Thinking both check the same thing
• Assuming authorization happens before authentication

2. Which Express middleware is typically used for authentication?

easy

A. passport.authenticate()

B. cors()

C. express.json()

D. express.static()

Solution

1. Step 1: Identify authentication middleware

   Passport.js is a popular Express middleware for handling authentication.

2. Step 2: Check other options

   express.static serves files, express.json parses JSON, cors handles cross-origin requests, none handle authentication.

3. Final Answer:

   passport.authenticate() -> Option A

4. Quick Check:

   passport.authenticate() = authentication middleware [OK]

Hint: Passport is for authentication in Express [OK]

Common Mistakes:

• Choosing express.static for authentication
• Confusing cors with authentication
• Not knowing passport middleware

3. Consider this Express route snippet:

app.get('/dashboard', (req, res) => {
  if (!req.user) {
    return res.status(401).send('Not authenticated');
  }
  if (!req.user.isAdmin) {
    return res.status(403).send('Not authorized');
  }
  res.send('Welcome Admin');
});

What status code will be sent if a logged-in user is not an admin?

medium

A. 200

B. 401

C. 403

D. 500

Solution

1. Step 1: Check authentication condition

   The code checks if req.user exists; if not, sends 401 (unauthenticated).

2. Step 2: Check authorization condition

   If user exists but isAdmin is false, sends 403 (forbidden, unauthorized).

3. Final Answer:

   403 -> Option C

4. Quick Check:

   Authenticated but not authorized = 403 [OK]

Hint: 401 = no login, 403 = no permission [OK]

Common Mistakes:

• Mixing 401 and 403 status codes
• Assuming 200 is sent without admin rights
• Ignoring the authorization check

4. This Express middleware aims to protect routes:

function checkAdmin(req, res, next) {
  if (!req.user.isAdmin) {
    res.status(401).send('Unauthorized');
  }
  next();
}

What is the bug here?

medium

A. req.user might be undefined causing an error

B. Should send status 403 instead of 401 for authorization failure

C. Missing call to next() inside the if block

D. Middleware should be async

Solution

1. Step 1: Analyze req.user usage

   The code accesses req.user.isAdmin without checking if req.user exists, risking a runtime error.

2. Step 2: Check other issues

   While 403 is better for authorization failure, the main bug is possible crash from undefined req.user.

3. Final Answer:

   req.user might be undefined causing an error -> Option A

4. Quick Check:

   Always check req.user exists before properties [OK]

Hint: Check req.user exists before isAdmin [OK]

Common Mistakes:

• Ignoring possible undefined req.user
• Confusing 401 and 403 status codes
• Not returning after sending response

5. You want to protect an Express route so only authenticated users with role 'editor' or 'admin' can access it. Which middleware logic correctly implements this authorization check?

hard

A. if (req.user && req.user.role === 'admin') { next(); } else { res.status(403).send('Forbidden'); }

B. if (!req.user && (req.user.role === 'editor' || req.user.role === 'admin')) { next(); } else { res.status(401).send('Unauthorized'); }

C. if (req.user.role === 'editor' || req.user.role === 'admin') { next(); } else { res.status(401).send('Unauthorized'); }

D. if (!req.user || (req.user.role !== 'editor' && req.user.role !== 'admin')) { res.status(403).send('Forbidden'); } else { next(); }

Solution

1. Step 1: Check authentication and authorization together

   The middleware must first confirm req.user exists (authenticated), then check if role is 'editor' or 'admin'.

2. Step 2: Analyze each option

   if (!req.user || (req.user.role !== 'editor' && req.user.role !== 'admin')) { res.status(403).send('Forbidden'); } else { next(); } correctly denies access if no user or role not allowed, sending 403 Forbidden. Others have logic errors or wrong status codes.

3. Final Answer:

   if (!req.user || (req.user.role !== 'editor' && req.user.role !== 'admin')) { res.status(403).send('Forbidden'); } else { next(); } -> Option D

4. Quick Check:

   Check user exists AND role allowed for authorization [OK]

Hint: Check user exists AND role matches before next() [OK]

Common Mistakes:

• Not checking if user is authenticated first
• Using wrong status codes (401 vs 403)
• Incorrect logical operators in role check