Pregunta 1Cuando el servidor guarda la contraseña de un usuario, ¿qué queda en la base de datos?
Cómo funciona el inicio de sesión — autenticación, sesiones y Cookies
Este artículo forma parte del curso Fundamentos de informática, que construye desde cero los conocimientos prácticos de informática que necesitas como mínimo para programar y hacer vibe coding.
La función de inicio de sesión se compone de la autenticación, que confirma que el usuario es quien dice ser, y de la sesión, que permite al servidor seguir reconociendo a ese mismo usuario después. Los diagramas muestran qué papel cumplen el hash y la Cookie.
Este artículo trata cómo funciona la función de inicio de sesión.
Esa función se compone de dos mecanismos: uno que confirma que el usuario es quien dice ser y otro que sigue reconociendo a ese mismo usuario después.
«Hash», «autenticación por sesión» y «JWT» son nombres distintos para las partes de una misma función de inicio de sesión.
La rama superior es la comprobación que se hace una sola vez; la inferior es la que se hace en cada solicitud posterior.
La autenticación confirma quién eres; la autorización decide qué puedes hacer
La autenticación (authentication: confirmar que el usuario es quien dice ser) es la decisión que se toma al iniciar sesión.
La autorización (authorization: decidir qué puede hacer ese usuario ya confirmado) es una decisión distinta que viene después.
Una solicitud: «eliminar esta reserva»
Decisión 1 — autenticación (¿es realmente tanaka?)
- En qué se basa — ID y contraseña; tras iniciar sesión, el ID de sesión de la Cookie
- Si no pasa — devolver al usuario a la pantalla de inicio de sesión
- La contraseña se comprueba una vez; después, el ID de sesión
Decisión 2 — autorización (¿se puede eliminar esta reserva?)
- En qué se basa — quién es el dueño de la reserva y si el usuario es administrador
- Si no pasa — devolver «no tienes permisos»
- Se comprueba cada vez que se realiza una acción
Aunque las acciones sean del mismo tanaka, las dos se deciden por separado.
Algunas filas se detienen en la autenticación y otras pasan la autenticación y se detienen en la autorización.
Ajustes como «solo administradores» o «solo ves tus propios datos» son autorización.
La autenticación confirma quién eres; la autorización decide qué puedes hacer
Poder iniciar sesión y tener permiso para realizar una acción se deciden por separado.
La autenticación confirma si el usuario es quien dice ser, la autorización decide si ese usuario puede realizar esa acción, y la autorización se comprueba en el servidor cada vez que se realiza una acción.
Las contraseñas se guardan como hash, y los hashes se comparan con hashes
Lo primero que hay que entender de la autenticación es que el servidor no guarda la contraseña en sí.
Lo que guarda es un hash (hash: una cadena creada a partir de la cadena original mediante un procedimiento fijo, que no se puede revertir).
| Lo que escribes | Hash calculado en el momento | Comparado con el hash guardado | Resultado |
|---|---|---|---|
| hanabi2026 (correcta) | a3f9...c1 | Igual que a3f9...c1 | Inicio de sesión correcto |
| hanabi2025 (un carácter distinto) | 7b20...e4 | Distinto de a3f9...c1 | Inicio de sesión fallido |
| Hanabi2026 (mayúscula distinta) | d15c...8a | Distinto de a3f9...c1 | Inicio de sesión fallido |
Basta con que cambie un carácter para que el hash resultante sea completamente distinto.
La comprobación funciona aunque el hash no se pueda revertir, porque aquello con lo que se compara también es un hash.
Lo único que tiene el servidor es una cadena que no se puede revertir.
La base de datos de my-app
Una fila de la tabla users (tanaka)
- email — tanaka@example.com
- password_hash — a3f9...c1
- created_at — la fecha y hora en que se creó la cuenta
Lo que esta fila no contiene
- Los caracteres escritos hanabi2026
- Cualquier dato que se pueda convertir de nuevo en los caracteres escritos
- Si el usuario tiene la sesión iniciada en este momento
Las contraseñas se guardan como hash por si el contenido de la base de datos se filtra.
Las cadenas de uso frecuente se pueden adivinar, así que antes de calcular el hash se añade una cadena distinta para cada usuario (un salt).
El HTTPS del envío protege los datos para que no se lean mientras se transmiten, que es algo distinto de la forma en que se guardan.
Lo guardado es un hash, y aquello con lo que se compara también es un hash
El servidor no tiene la contraseña que escribió el usuario.
Solo tiene una cadena que no se puede revertir y, en cada inicio de sesión, pasa los caracteres escritos por el mismo procedimiento y comprueba si la cadena resultante es igual a la guardada.
Tras iniciar sesión, el servidor sabe que eres la misma persona por el ID de sesión de la Cookie
Aunque el inicio de sesión sea correcto, la solicitud que abre la página siguiente es una solicitud distinta.
HTTP no tiene estado (stateless: cada intercambio no recuerda el anterior), así que el servidor no guarda quién ha iniciado sesión hace un momento.
El hecho de que el inicio de sesión sea correcto se registra en el servidor, y el navegador recibe una cadena que apunta a ese registro.
Ese registro que queda en el servidor es la sesión (session), la cadena que apunta a él es el ID de sesión (session ID), y el mecanismo que entrega esa cadena al navegador y hace que se envíe cada vez es la Cookie (cookie).
my-app después de iniciar sesión
Dentro del navegador de tanaka
- Cookie: session_id=3f9a1c...e81b
- Se adjunta automáticamente a cada solicitud al mismo sitio
- No tiene nada más que esta cadena
Dentro del servidor
- El registro de sesión 3f9a1c...e81b es tanaka
- Este registro tiene una fecha de caducidad
- Al cerrar sesión se elimina este registro
En el lado del navegador solo está la cadena 3f9a1c...e81b, que no contiene ni el nombre ni los permisos.
De quién es la sesión solo se sabe cuando esa cadena se relaciona con el registro del servidor.
Solo la fila de arriba se relaciona con un registro, así que la lista de reservas se devuelve sin volver a pedir la contraseña.
Este intercambio tiene la forma de las dos líneas siguientes.
# Línea que devuelve el servidor cuando el inicio de sesión es correcto
Set-Cookie: session_id=3f9a1c...e81b; HttpOnly; Secure
# A partir de ahí, línea que se adjunta a cada solicitud que el navegador envía al mismo sitio
Cookie: session_id=3f9a1c...e81b
Los dos elementos que van después de Set-Cookie son instrucciones para el navegador.
HttpOnly impide que el JavaScript de la página lea esta Cookie, y Secure hace que solo se envíe por HTTPS.
El contenido de una Cookie lo puede modificar el usuario, así que el resultado cambia según si se confía en él tal como llega.
Una Cookie se guarda en el navegador, así que el usuario puede modificar su contenido y enviarlo.
En la Cookie se pone solo el ID de sesión, y la decisión se toma con el registro del servidor.
En la caja de la izquierda solo hay una cadena sin significado propio.
Todo lo que decide quién es un usuario y qué puede hacer está dentro de la caja de la derecha.
El navegador recibe una sola cadena que apunta al registro
Cuando llega una solicitud, el servidor no sabe de quién es.
Lo sabe porque el registro creado al iniciar sesión y la cadena que el navegador envía cada vez se relacionan, y si el registro se elimina o caduca, enviar la misma cadena te devuelve a la pantalla de inicio de sesión.
Autenticación por sesión frente a JWT — ¿tiene el registro el servidor o lo tiene la cadena?
«Autenticación por sesión o JWT» es una elección sobre qué lado guarda la prueba de haber iniciado sesión.
La otra forma no deja ningún registro en el servidor y entrega la prueba misma al navegador.
La cadena de prueba que se adjunta y se envía cada vez es un token (token), y JWT (JSON Web Token: una cadena que reúne el ID del usuario, la fecha de caducidad y una firma) es el formato más conocido.
Una cadena que el navegador adjunta y envía cada vez (JWT)
Contenido — de quién es y hasta cuándo es válido
- El ID de usuario de tanaka
- Fecha de caducidad (válido hasta ese momento)
Firma — un valor que solo el servidor puede generar
- Una cadena calculada a partir del contenido
- Si se modifica el contenido, el cálculo deja de coincidir
Gracias a la firma, el servidor sabe que la cadena recibida es una que él mismo emitió, sin compararla con ningún registro.
| Aspecto | Autenticación por sesión | JWT |
|---|---|---|
| Lo que se entrega cuando el inicio de sesión es correcto | session_id=3f9a1c...e81b | eyJhbGci... ID, caducidad y firma |
| Dónde está la base de la decisión | En un registro dentro del servidor | En el contenido de la cadena |
| Cómo se comprueba cada vez | Comparándola con el registro | Verificando la firma |
Un JWT lleva su contenido, así que se puede aceptar sin que haya un registro en el servidor.
Con la autenticación por sesión, al eliminar el registro la siguiente solicitud ya no pasa.
Un JWT pasa hasta que llega su caducidad, así que cuando quieres detenerlo de inmediato guardas aparte una lista de los que has revocado.
En este artículo hemos dibujado la autenticación por sesión como una Cookie y el JWT como una cadena, pero en la práctica también hay configuraciones que ponen el JWT dentro de una Cookie.
Aunque cambie dónde se guarda, la diferencia sigue siendo la misma: comparar con un registro o verificar una firma.
¿Tiene el registro el servidor o tiene la cadena el contenido entero?
En las dos formas, el navegador adjunta y envía una cadena cada vez.
Lo que cambia es lo que hace el servidor al recibirla: la autenticación por sesión consulta su propio registro, mientras que el JWT verifica la firma que lleva la cadena.
QUIZ
Verificación de conocimientos
Responde cada pregunta una a una.
Pregunta 2Cuando abres otra página después de iniciar sesión, ¿por qué sabe el servidor que eres el mismo usuario?
Pregunta 3Un usuario con la sesión iniciada intentó eliminar la reserva de otra persona y el servidor lo rechazó. ¿Qué decisión es esta?