JWT token verification middleware in Express - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What does this JWT verification middleware do?

Consider this Express middleware that verifies a JWT token from the request header. What will happen if the token is missing?

Express

import jwt from 'jsonwebtoken';

const verifyToken = (req, res, next) => {
  const token = req.headers['authorization'];
  if (!token) {
    return res.status(401).json({ message: 'No token provided' });
  }
  jwt.verify(token, 'secretkey', (err, decoded) => {
    if (err) {
      return res.status(403).json({ message: 'Failed to authenticate token' });
    }
    req.userId = decoded.id;
    next();
  });
};

export default verifyToken;

A The middleware throws an error and crashes the server.

B The middleware calls next() without any checks and allows the request to continue.

C The middleware sends a 403 response with message 'Failed to authenticate token' immediately.

D The middleware sends a 401 response with message 'No token provided' and stops further processing.

💡 Hint

Think about what happens when the token is not found in the headers.

If the token is missing, the middleware returns a 401 status and a message, stopping the request from continuing.

📝 Syntax

intermediate

Which option correctly verifies a JWT token asynchronously?

Choose the code snippet that correctly verifies a JWT token using the jsonwebtoken library in Express middleware.

A jwt.verify(token, 'secretkey', (err, decoded) => { if (err) return res.status(403).send('Invalid token'); req.user = decoded; next(); });

B const decoded = jwt.verify(token, 'secretkey'); req.user = decoded; next();

C jwt.verify(token, 'secretkey', (decoded, err) => { if (err) return res.status(403).send('Invalid token'); req.user = decoded; next(); });

D jwt.verify(token, (err, decoded) => { if (err) return res.status(403).send('Invalid token'); req.user = decoded; next(); });

💡 Hint

Remember the order of parameters in the callback for jwt.verify.

The callback receives err first, then decoded. Option A uses the correct order and parameters.

🔧 Debug

advanced

Why does this JWT middleware crash the server?

Look at this middleware code. Why does it crash the server when an invalid token is sent?

Express

import jwt from 'jsonwebtoken';

const verifyToken = (req, res, next) => {
  const token = req.headers['authorization'];
  const decoded = jwt.verify(token, 'secretkey');
  req.userId = decoded.id;
  next();
};

export default verifyToken;

A Because next() is called before jwt.verify completes.

B Because the token is missing and the code does not check for it.

C Because jwt.verify throws an error on invalid token and it is not caught, crashing the server.

D Because the secret key is incorrect.

💡 Hint

Think about what happens when jwt.verify fails without a try-catch.

jwt.verify throws an error if the token is invalid. Without a try-catch, this error crashes the server.

❓ state_output

advanced

What is the value of req.userId after this middleware runs with a valid token?

Given this middleware and a valid JWT token with payload { id: 42 }, what will req.userId be?

Express

import jwt from 'jsonwebtoken';

const verifyToken = (req, res, next) => {
  const token = req.headers['authorization'];
  jwt.verify(token, 'secretkey', (err, decoded) => {
    if (err) {
      return res.status(403).json({ message: 'Invalid token' });
    }
    req.userId = decoded.id;
    next();
  });
};

export default verifyToken;

A 42

B undefined

C null

D Throws an error

💡 Hint

Check how the decoded token payload is assigned to req.userId.

The decoded token contains { id: 42 }, so req.userId is set to 42.

🧠 Conceptual

expert

Why is it important to call next() only after successful JWT verification?

In Express middleware for JWT verification, why should next() be called only after the token is verified successfully?

A To improve server performance by skipping token verification for all requests.

B To prevent unauthorized requests from reaching protected routes by stopping the request early.

C To allow all requests to pass through regardless of token validity.

D To automatically refresh the JWT token for the user.

💡 Hint

Think about security and what happens if next() is called too early.

Calling next() only after verification ensures only authorized users access protected routes.

Practice

1. What is the main purpose of JWT token verification middleware in an Express app?

easy

A. To check if the incoming request has a valid JWT token before allowing access

B. To store user sessions on the server

C. To encrypt the user's password before saving

D. To serve static files like images and CSS

Solution

1. Step 1: Understand JWT middleware role

   JWT middleware checks the token sent by the client to confirm identity.

2. Step 2: Compare options with JWT purpose

   Only "To check if the incoming request has a valid JWT token before allowing access" describes verifying a token before access, which is the middleware's job.

3. Final Answer:

   To check if the incoming request has a valid JWT token before allowing access -> Option A

4. Quick Check:

   JWT middleware verifies token [OK]

Hint: JWT middleware always verifies token validity before access [OK]

Common Mistakes:

• Confusing JWT with session storage
• Thinking JWT middleware encrypts passwords
• Assuming middleware serves static files

2. Which of the following is the correct way to extract the JWT token from the Authorization header in Express middleware?

easy

A. const token = req.headers.authorization.split(' ')[1];

B. const token = req.body.token;

C. const token = req.query.token;

D. const token = req.cookies.token;

Solution

1. Step 1: Identify standard JWT token location

   JWT tokens are usually sent in the Authorization header as 'Bearer token'.

2. Step 2: Extract token correctly

   Splitting the header string by space and taking the second part gets the token.

3. Final Answer:

   const token = req.headers.authorization.split(' ')[1]; -> Option A

4. Quick Check:

   Authorization header split [OK]

Hint: JWT token is after 'Bearer ' in Authorization header [OK]

Common Mistakes:

• Trying to get token from body or query instead of header
• Not splitting the header string
• Assuming token is in cookies by default

3. Given this Express JWT middleware snippet, what happens if the token is invalid?

const jwt = require('jsonwebtoken');
function verifyToken(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.status(401).send('Access denied');
  try {
    const verified = jwt.verify(token, 'secretkey');
    req.user = verified;
    next();
  } catch (err) {
    res.status(400).send('Invalid token');
  }
}

medium

A. The middleware calls next() and allows access

B. The middleware crashes with an unhandled exception

C. The middleware sends a 401 status with 'Access denied' message

D. The middleware sends a 400 status with 'Invalid token' message

Solution

1. Step 1: Check token verification flow

   If token is invalid, jwt.verify throws an error caught by catch block.

2. Step 2: Observe catch block response

   Catch block sends status 400 with message 'Invalid token'.

3. Final Answer:

   The middleware sends a 400 status with 'Invalid token' message -> Option D

4. Quick Check:

   Invalid token triggers 400 response [OK]

Hint: Invalid token triggers catch block sending 400 error [OK]

Common Mistakes:

• Confusing 401 and 400 status codes
• Assuming next() is called on invalid token
• Thinking middleware crashes on invalid token

4. Identify the error in this JWT verification middleware code:

const jwt = require('jsonwebtoken');
function verifyToken(req, res, next) {
  const token = req.headers.authorization.split(' ')[1];
  if (!token) res.status(401).send('Access denied');
  try {
    const verified = jwt.verify(token, 'secretkey');
    req.user = verified;
    next();
  } catch (err) {
    res.status(400).send('Invalid token');
  }
}

medium

A. jwt.verify is called with wrong secret key

B. Missing return after sending 401 response causes jwt.verify to run anyway

C. Token is extracted incorrectly from headers

D. next() is called inside catch block instead of try block

Solution

1. Step 1: Check handling when token is missing

   If token is missing, res.status(401).send() is called but no return statement stops execution.

2. Step 2: Understand consequence of missing return

   Without return, code continues and jwt.verify runs with undefined token, causing errors or unexpected behavior.

3. Final Answer:

   Missing return after sending 401 response causes jwt.verify to run anyway -> Option B

4. Quick Check:

   Return needed after 401 response [OK]

Hint: Always return after sending response to stop middleware [OK]

Common Mistakes:

• Forgetting to return after res.send()
• Assuming jwt.verify secret is wrong here
• Misreading token extraction line

5. You want to protect multiple routes with JWT verification but also allow public access to some routes. Which is the best way to apply JWT middleware in Express?

hard

A. Apply JWT middleware after route handlers to catch errors

B. Apply JWT middleware globally to all routes and skip it conditionally inside middleware

C. Apply JWT middleware only to protected routes using router.use or route-specific middleware

D. Apply JWT middleware only once in app.listen callback

Solution

1. Step 1: Understand middleware scope

   Applying middleware globally affects all routes, including public ones, which is not ideal.

2. Step 2: Use route-specific middleware for protection

   Applying JWT middleware only on protected routes keeps public routes accessible without token.

3. Final Answer:

   Apply JWT middleware only to protected routes using router.use or route-specific middleware -> Option C

4. Quick Check:

   Protect routes selectively with middleware [OK]

Hint: Use middleware only on routes needing protection [OK]

Common Mistakes:

• Applying middleware globally and skipping inside code
• Applying middleware after route handlers
• Trying to apply middleware in app.listen