How would you use Next.js Middleware to protect /api/admin/* routes?

WHAT THIS TESTS: This question tests whether you understand that Next.js Middleware runs in the Edge Runtime and therefore cannot rely on Node.js-specific authentication helpers or the client-side session object. It specifically probes your knowledge of the NextAuth.js session model, where the client session contains only a minimal user payload and an expiry date, while the actual session token resides in a secure cookie. The interviewer wants to see if you know how to intercept a request, inspect cookies, perform lightweight token validation, and decide whether to block the request or allow it to reach the Route Handler.

A GOOD ANSWER COVERS: First, match the middleware config to /api/admin/:path* so it runs before any admin route handler. Second, extract the secure session cookie from the request headers, not the client session object. Third, validate the token, for example by verifying a JWT signature and checking the expiration, keeping in mind Edge Runtime constraints like limited Node.js APIs. Fourth, return a 401 or 403 response if the token is missing or invalid, or call NextResponse.next() to continue to the handler. Fifth, acknowledge that complex role-based access control should often live in the Route Handler itself because Middleware is meant to be fast and stateless, and database lookups can be expensive or incompatible at the edge.

COMMON WRONG ANSWERS: A major red flag is suggesting useSession inside Middleware, since that hook is client-side only and depends on React context. Another is trusting the minimal client session payload for security decisions, because NextAuth.js explicitly states that the session object returned to the client does not contain the session token and is for presentation only. Candidates also err by proposing heavy database queries or Prisma calls inside Middleware, which can fail or add unacceptable latency in the Edge Runtime. Finally, forgetting to handle the matcher config and instead running middleware on every route shows a lack of production awareness.

LIKELY FOLLOW-UPS: The interviewer might ask how you would refresh an expired token at the edge, or how you would pass the decoded user context from Middleware down to the Route Handler without re-verifying the token. They may also ask what happens if the Edge Runtime does not support your token verification library, or how you would rate-limit these admin routes in Middleware.

ONE CONCRETE EXAMPLE: Suppose an admin dashboard lives at /api/admin/reports. In middleware.ts, you export a config with matcher set to /api/admin/:path*. Inside the middleware function, you read request.cookies.get with the name next-auth.session-token. You use a lightweight JWT verification library compatible with the Edge Runtime to check the signature against your secret. If valid, you call NextResponse.next(). If the cookie is missing, you return a new NextResponse with the body Unauthorized and status 401. The Route Handler at /api/admin/reports then handles fine-grained permission checks, such as ensuring the user has an admin role, because Middleware has already guaranteed that a valid session exists.