La autenticación con middleware en Next.js te permite decidir, antes de renderizar una página, si un usuario tiene permiso para acceder a una ruta protegida. Aquí verás cómo interceptar peticiones, leer cookies y redirigir al login cuando la sesión no existe, todo desde un único archivo middleware.ts.

¿Qué es la autenticación y por qué usar middleware en Next.js?

La autenticación es el mecanismo que verifica si quien navega tu aplicación tiene permiso para entrar a ciertas páginas. Cuando combinas esa lógica con el middleware de Next.js, evalúas la petición antes de que llegue a la página y rediriges al usuario según corresponda.

Esa decisión ocurre en el servidor, en cada navegación, y se apoya en datos como la cookie de sesión que vive en el navegador y viaja con cada request.

¿Qué hace el middleware en Next.js? Intercepta cada request antes de renderizar la página y te deja leer cookies, validar permisos y redirigir al usuario sin tocar el componente.

¿Cómo proteger rutas con el middleware de Next.js?

El flujo es directo: cuando entras a una ruta dentro de /auth distinta de /auth/login, el middleware revisa la cookie de sesión. Si existe, te deja continuar. Si no, te manda al login.

¿Dónde vive el archivo middleware.ts?

El archivo middleware.ts se ubica en la raíz del proyecto, no dentro de app ni de pages. Exportas una función llamada middleware que recibe el request y desde ahí tomas decisiones según el pathname.

Dentro de esa función filtras por la ruta que te interesa proteger. En el ejemplo, solo actúas si la URL empieza con /auth y es diferente de /auth/login, para evitar un bucle de redirecciones hacia la propia página de login.

¿Cómo leer cookies asíncronas en el middleware?

Las cookies en Next.js ahora son asíncronas, así que necesitas await para acceder a ellas:

ts import { cookies } from 'next/headers' import { NextResponse } from 'next/server' import { isSessionValid, sessionCookieName } from '@/utils/auth'

export async function middleware(request) { const { pathname } = request.nextUrl

if (pathname.startsWith('/auth') && pathname !== '/auth/login') { const allCookies = await cookies() const sessionCookie = allCookies.get(sessionCookieName)?.value

const hasSession = await isSessionValid(sessionCookie)

if (hasSession) {
  return NextResponse.next()
}

const loginUrl = new URL('/auth/login', request.nextUrl)
return NextResponse.redirect(loginUrl)

} }

Fíjate en el operador ?.value: si la cookie no existe, te devuelve undefined sin romper el código. Y guardar el nombre de la cookie en una constante como sessionCookieName te permite reusarlo en todos los archivos sin repetir strings.

¿Por qué usar new URL en lugar de un string en redirect? Porque conserva los search params de la URL original (como redirect, name u otros), heredándolos desde request.nextUrl y evitando que pierdas información en la redirección.

¿Cómo validar la cookie de sesión paso a paso?

La función isSessionValid se mantiene básica a propósito: recibe un string y retorna una promesa que resuelve un booleano. Por ahora, solo comprueba que la cookie tenga algún valor.

ts export async function isSessionValid(cookie?: string): Promise<boolean> { return Boolean(cookie) }

El Boolean() actúa como un cast: si la cookie está vacía o es undefined, devuelve false. Si tiene contenido, devuelve true. En una aplicación real, aquí validarías firma, expiración o consultarías una base de datos, pero el foco de esta lógica está en el middleware.

¿Qué pasa cuando el usuario no tiene sesión?

Si hasSession es false, el middleware ejecuta NextResponse.redirect apuntando a /auth/login. El usuario ve la página de login, ingresa el secreto (en el ejemplo, nunca pares de aprender) y el sistema crea una cookie llamada sesión que puedes inspeccionar en DevTools → Application → Cookies.

A partir de ese momento, cuando vuelves a la ruta protegida, el middleware lee la cookie, isSessionValid retorna true y NextResponse.next() te deja pasar al contenido.

¿Qué habilidades y conceptos clave aparecen en la clase?

Estos son los puntos técnicos que vale la pena tener claros antes de avanzar al manejo de sesiones con Server Actions:

• Middleware de Next.js [0:38]: función exportada desde middleware.ts en la raíz que intercepta requests.
• Filtrado por pathname [2:18]: condicional sobre request.nextUrl.pathname para actuar solo en rutas específicas.
• Cookies asíncronas [3:05]: uso de await cookies() desde next/headers para leer la sesión.
• Operador opcional ?.value [3:55]: protege contra cookies inexistentes sin lanzar error.
• NextResponse.next y NextResponse.redirect [4:30]: las dos decisiones posibles del middleware, continuar o redirigir.
• Construcción de URL con new URL [4:50]: preserva search params del request original al redirigir.
• Cast booleano con Boolean() [5:45]: convierte un string posiblemente vacío en true o false para tomar decisiones.
• Constante sessionCookieName [3:40]: centraliza el nombre de la cookie en utils/auth para reusarla en toda la app.

En la siguiente clase verás cómo crear esa cookie desde Server Actions, escribir la sesión y cerrar el ciclo completo de autenticación. ¿Cómo proteges tus rutas hoy en Next.js? Cuéntalo en los comentarios.