COOKIES

Las cookies sirven para almacenar información en el navegador, de manera similar a sessionStorage o localStorage. Sin embargo, las cookies tienen opciones que pueden hacerlas más seguras. Por ejemplo:

• HttpOnly: Restringe la cookie para que no sea accedida desde JavaScript.
• Secure: Indica a la cookie que solo puede ser enviada a servidores o URLs con SSL (Secure Sockets Layer).
• SameSite: Previene el envío de la cookie en solicitudes cross-site, lo que ayuda a mitigar el riesgo de ataques de tipo cross-site request forgery (CSRF).
• Expires: Establece una fecha de expiración para la cookie. Después de esta fecha, la cookie será eliminada automáticamente.
• Max-Age: Establece la antigüedad máxima de la cookie en segundos. Cuando se alcanza esta antigüedad, la cookie se elimina automáticamente. Si se establecen Expires y Max-Age, Max-Age tiene prioridad.
• Domain: Indica a qué dominio pertenece la cookie. Solo se enviará la cookie a este dominio.
• Path: Define el camino que debe seguir la cookie dentro del dominio especificado. Solo se enviará la cookie a este camino.

Las cookies se pueden configurar desde el back mediante el encabezado Set-Cookie y viajan en los headers de la respuesta HTTP. Se establecen en el navegador con la clave-valor asignados en el back. De manera automática, el navegador reconoce qué dominio establece la cookie y la reenvía en los headers del request, específicamente en el header Cookie, en cada solicitud que se haga a ese dominio que la generó. Las cookies generadas en el back, pueden utilizar la opción HttpOnly.

SESSION ID

El Session ID es un identificador alfanumérico generado en el back que se envía al front a través de una cookie. Usualmente se utilizan las opciones HttpOnly y Secure para mejorar la seguridad. Este ID es validado en el servidor cada vez que retorna en una petición; es útil para hacer seguimiento de quién es el usuario que está accediendo a los diferentes endpoints.

JWT (JSON Web Token)

El JWT es un tipo de token que puede contener información del usuario en su payload. Usualmente, se devuelve el token en el cuerpo (body) de la respuesta cuando un usuario inicia sesión en un sistema y es responsabilidad del frontend recuperarlo y guardarlo para posteriormente enviarlo manualmente en los headers. En concreto, se envía en el header Authorization: Bearer tokenJWT.

Otra opción es generarlo en el servidor y guardarlo en una cookie con las opciones Secure y HttpOnly. En este caso su valor se debe recuperar de los headers de la petición y hacer la validación una vez entre en el endpoint del backend.

Depende de la aplicación y del programador el uso de sesiones con JWT, su uso con estado (stateful) o sin estado (stateless); en este último caso, analizar el tiempo de expiración del token para evitar información obsoleta, como por ejemplo datos de un rol que acaba de ser revocado al usuario.