Autenticación con JWT y bcrypt

La autenticación tiene dos momentos diferentes: verificar una credencial y demostrar después que una solicitud pertenece a una sesión válida. En un portal de consultas, la contraseña se compara con un hash almacenado; el token posterior identifica al usuario, pero no debe contener la contraseña ni datos innecesarios.

Ejemplo resuelto

Para el usuario lina@ejemplo.test, el registro guarda passwordHash, nunca password. Durante el acceso, una comparación positiva permite emitir un token con sub: "u17" y rol: "bibliotecaria". El middleware lee Authorization: Bearer <token>, verifica firma, algoritmo permitido, emisor, audiencia y caducidad, y coloca los claims validados en req.user; una firma inválida produce 401. Exige una expiración al emitir tokens, no aceptes tokens sin ella por defecto. Un JWT firmado no cifra su contenido: nunca incluyas secretos.

Pruébalo

1. Registra una contraseña transformada en hash.

2. Compara la contraseña recibida sin guardar su texto.

3. Emite un token con identificador y rol mínimos.

4. Protege una ruta y prueba ausencia, token inválido y token válido.

Error frecuente: devolver el hash en la respuesta o aceptar cualquier texto decodificado como token. Corrígelo excluyendo el campo sensible y verificando los claims antes de confiar en el contenido. Con bcrypt, rechaza contraseñas que excedan 72 bytes UTF-8 en vez de truncarlas silenciosamente; caracteres acentuados pueden ocupar varios bytes. El permiso de bibliotecaria requiere además autorización vigente del servidor.

Comprueba tu resultado

El registro no contiene la contraseña original. La prueba también rechaza un token caducado y uno con audiencia incorrecta; conocer un rol en el token no sustituye comprobar permisos actuales. Sin cabecera y con token inválido obtienes 401; con token válido, req.user.sub vale u17. Una contraseña incorrecta no emite token ni modifica datos.