JWT vs session strategy in NextJS - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding JWT vs Session Storage

Which of the following best describes a key difference between JWT and session-based authentication strategies in Next.js?

A Sessions are stateless and do not require server memory, JWTs always require server memory.

B JWT requires server-side storage for each user session, sessions do not.

C JWTs cannot be used for authentication in Next.js applications.

D JWT stores user data on the client side, while sessions store data on the server side.

💡 Hint

Think about where the user data is kept in each method.

JWTs store user information encoded in a token on the client side, so the server does not need to keep session data. Sessions keep user data on the server, linked by a session ID stored in a cookie.

❓ component_behavior

intermediate

Next.js API Route with JWT Authentication

Given a Next.js API route that verifies a JWT token from the Authorization header, what will happen if the token is missing or invalid?

NextJS

export default async function handler(req, res) {
  const authHeader = req.headers.authorization;
  if (!authHeader) {
    return res.status(401).json({ error: 'No token provided' });
  }
  const token = authHeader.split(' ')[1];
  try {
    const user = verifyToken(token); // throws if invalid
    res.status(200).json({ user });
  } catch {
    res.status(403).json({ error: 'Invalid token' });
  }
}

A Responds with 403 status and 'Invalid token' error if token is missing.

B Responds with 200 status and empty user object if token is missing.

C Responds with 401 status and 'No token provided' error if token is missing.

D Throws a server error and crashes the API route.

💡 Hint

Check the condition for missing token before verification.

If the Authorization header is missing, the code returns a 401 error with 'No token provided'. If the token is invalid, it returns 403 with 'Invalid token'.

❓ state_output

advanced

Session Storage Behavior in Next.js

In a Next.js app using session-based authentication, what will be the value of req.session.user after a user logs out?

NextJS

export default async function handler(req, res) {
  if (req.method === 'POST' && req.url === '/logout') {
    req.session.destroy();
    res.status(200).json({ message: 'Logged out' });
  } else {
    res.status(200).json({ user: req.session.user || null });
  }
}

A null, because the session is destroyed and user data is removed.

B An empty object {}, because the session remains but user data is cleared.

C The previous user object, because session destruction is asynchronous and not immediate.

D Undefined, because req.session is deleted entirely.

💡 Hint

Consider what happens to session data after calling destroy().

Calling req.session.destroy() removes the session and all its data, so req.session.user will be null or undefined after logout.

📝 Syntax

advanced

Correct JWT Verification Syntax in Next.js

Which option correctly verifies a JWT token using the jsonwebtoken library in a Next.js API route?

NextJS

import jwt from 'jsonwebtoken';

export default function handler(req, res) {
  const token = req.headers.authorization?.split(' ')[1];
  try {
    // Verify token here
  } catch (err) {
    res.status(401).json({ error: 'Unauthorized' });
  }
}

A const user = jwt.verify(token, process.env.JWT_SECRET);

B const user = jwt.decode(token, process.env.JWT_SECRET);

C const user = jwt.verify(token);

D const user = jwt.decode(token);

💡 Hint

Which method checks the token signature using a secret?

jwt.verify checks the token's signature using the secret key. jwt.decode only decodes without verifying.

🔧 Debug

expert

Debugging Token Expiry Handling in Next.js

A Next.js API route uses JWT for authentication. The code catches errors during verification but does not distinguish token expiry errors. What is the likely user experience when a token expires?

NextJS

try {
  const user = jwt.verify(token, process.env.JWT_SECRET);
  res.status(200).json({ user });
} catch (err) {
  res.status(401).json({ error: 'Unauthorized' });
}

A User is redirected to login automatically without error message.

B User always sees 'Unauthorized' error without knowing the token expired.

C User receives a specific 'Token expired' error message.

D The API route crashes due to unhandled token expiry error.

💡 Hint

Check how errors are handled in the catch block.

The catch block returns a generic 'Unauthorized' error for all verification failures, including expired tokens, so users do not get a specific expiry message.

Practice

1. What is a key difference between JWT and session strategies in Next.js authentication?

easy

A. JWT stores user info on the client, sessions store it on the server

B. JWT requires server storage, sessions do not

C. Sessions are better for scaling across devices than JWT

D. JWT tokens expire immediately after login

Solution

1. Step 1: Understand JWT storage

   JWT stores user information inside a token on the client side, allowing stateless authentication.

2. Step 2: Understand session storage

   Sessions keep user information on the server, maintaining state and control centrally.

3. Final Answer:

   JWT stores user info on the client, sessions store it on the server -> Option A

4. Quick Check:

   Storage location difference = B [OK]

Hint: Remember: JWT = client, session = server [OK]

Common Mistakes:

• Thinking sessions store data on client
• Believing JWT requires server storage
• Confusing scaling benefits

2. Which code snippet correctly initializes a session in Next.js using a session strategy?

easy

A. const session = localStorage.getItem('session');

B. const token = jwt.sign(payload, secret);

C. import { getSession } from 'next-auth/react'; const session = await getSession();

D. import jwt from 'jsonwebtoken'; const token = jwt.verify(tokenString, secret);

Solution

1. Step 1: Identify session initialization

   Using 'getSession' from 'next-auth/react' is the correct way to get session data in Next.js.

2. Step 2: Check other options

   Options B and D relate to JWT token creation and verification, not sessions. const session = localStorage.getItem('session'); uses localStorage, which is client-side and not a session strategy.

3. Final Answer:

   import { getSession } from 'next-auth/react'; const session = await getSession(); -> Option C

4. Quick Check:

   Session retrieval uses getSession() [OK]

Hint: Sessions use getSession(), JWT uses jwt.sign() [OK]

Common Mistakes:

• Confusing JWT token code with session code
• Using localStorage as session storage
• Missing async/await with getSession

3. Given this Next.js API route using JWT, what will be the response if the token is expired?

import jwt from 'jsonwebtoken';
export default function handler(req, res) {
  try {
    const token = req.headers.authorization?.split(' ')[1];
    jwt.verify(token, process.env.JWT_SECRET);
    res.status(200).json({ message: 'Access granted' });
  } catch (err) {
    res.status(401).json({ error: 'Invalid or expired token' });
  }
}

medium

A. 200 with message 'Access granted'

B. 401 with error 'Invalid or expired token'

C. 500 server error

D. 403 forbidden without message

Solution

1. Step 1: Understand jwt.verify behavior

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

2. Step 2: Check catch block response

   The catch block sends a 401 status with error message 'Invalid or expired token'.

3. Final Answer:

   401 with error 'Invalid or expired token' -> Option B

4. Quick Check:

   Expired token triggers 401 error [OK]

Hint: Expired JWT triggers catch block with 401 [OK]

Common Mistakes:

• Assuming expired token returns 200
• Confusing 403 and 401 status codes
• Missing try-catch around jwt.verify

4. Identify the bug in this Next.js session handling code snippet:

import { getSession } from 'next-auth/react';
export default async function handler(req, res) {
  const session = getSession();
  if (!session) {
    res.status(401).json({ error: 'Not authenticated' });
  } else {
    res.status(200).json({ message: 'Welcome!' });
  }
}

medium

A. Missing await before getSession()

B. Using getSession() instead of getServerSession()

C. No error handling for session retrieval

D. Incorrect status code for authenticated user

Solution

1. Step 1: Check the context

   This is a Next.js API route (server-side).

2. Step 2: Identify correct function for server-side

   While getServerSession() is recommended for server-side session retrieval, the immediate bug in the code is missing await before the async getSession() call, causing session to be a Promise instead of resolved value.

3. Final Answer:

   Missing await before getSession() -> Option A

4. Quick Check:

   Async function requires await to get session value [OK]

Hint: Async calls need await [OK]

Common Mistakes:

• Forgetting await on async functions
• Confusing getSession and getServerSession
• Ignoring promise returned by getSession

5. You want to build a Next.js app that supports multiple devices per user and scales easily without server state. Which strategy fits best and why?

hard

A. Use sessions because they store data on the server for better control

B. Use sessions with database storage for multi-device support

C. Use JWT but store tokens only on the server

D. Use JWT because tokens store user info on client, enabling stateless scaling

Solution

1. Step 1: Analyze multi-device and scaling needs

   Supporting multiple devices and easy scaling requires stateless authentication without server session storage.

2. Step 2: Match strategy to needs

   JWT stores user info in tokens on the client, allowing stateless, scalable authentication across devices.

3. Final Answer:

   Use JWT because tokens store user info on client, enabling stateless scaling -> Option D

4. Quick Check:

   Stateless multi-device = JWT [OK]

Hint: Stateless multi-device apps use JWT [OK]

Common Mistakes:

• Choosing sessions for stateless scaling
• Thinking JWT tokens must be stored on server
• Assuming sessions easily scale without extra setup