Verificar un JSON Web Token (JWT) es el paso que cierra el ciclo de autenticación: confirma que el token recibido es genuino y no ha sido alterado. Aquí aprendes cómo hacerlo en Node.js con firma simétrica (HS256) y asimétrica (RS256), cuándo usar cada una y qué riesgos evitar al exponer claves.

¿Cómo verificar un JWT en Node.js paso a paso?

La verificación se apoya en la misma librería que usaste para firmar. El método jwt.verify recibe el token en formato de serialización compacta, esas tres partes codificadas en base64 separadas por puntos que ya conoces [01:00].

El segundo parámetro depende del algoritmo:

• El secret compartido si firmaste con HS256.
• La llave pública si firmaste con RS256.
• Opciones extra o un callback como tercer argumento.

Dentro del endpoint privado, después de extraer el token de los headers, basta con llamar jwt.verify(token, secret). Una sola línea hace el trabajo [01:30].

¿Qué hace jwt.verify exactamente? Recalcula la firma del token usando el secret o la llave pública y la compara con la firma original. Si coinciden y el token no expiró, lo considera válido.

¿Cómo probar la verificación con Postman?

Al llamar el endpoint privado con un token expirado, recibes un error. Eso es buena señal: significa que la verificación funciona. Si pides un token nuevo y repites la llamada, la respuesta I'm private confirma que todo fluye [02:15].

¿Cómo firmar un JWT de forma asimétrica con RS256?

La firma asimétrica usa un par de llaves: una privada que firma y una pública que verifica. Para generarlas, un script con OpenSSL crea los archivos en formato PKCS8 (Public Key Cryptographic Standard número 8), el más recomendado actualmente [03:30].

El resultado son dos archivos:

• private.pem con la llave privada.
• public.pem con la llave pública.

En el método de firmado, agregas un condicional: si existe privateKeyPath en las variables de entorno, lees el archivo con el módulo nativo de Node.js. La forma correcta de importarlo en proyectos ES Modules es node:fs, así le indicas explícitamente que es la librería oficial [05:00].

Con la llave cargada, retornas el token usando el payload, la privateKey y declaras en el tercer argumento que el algoritmo es RS256. Sin ese parámetro, la librería no sabría que estás firmando asimétricamente.

¿Cómo confirmar que el token usa RS256?

Una forma rápida es pegar el token en JWT.io. A la derecha aparece la decodificación del header y el payload, donde puedes confirmar que el algoritmo es RS256. La página incluso permite pegar la llave privada y pública para verificar la firma manualmente [06:30].

¿Cómo verificar un token firmado asimétricamente?

El ajuste en verifyToken es paralelo al del firmado. Con un condicional preguntas si existe publicKeyPath. Si es así, lees el archivo de la llave pública y se la pasas a jwt.verify en lugar del secret [07:30].

En este caso no necesitas declarar el algoritmo en las opciones: la librería lo infiere desde el header del token. Cargas la variable de entorno con la ruta del archivo y la verificación queda lista.

Un detalle útil del flujo de pruebas: en la pestaña de test de Postman puedes guardar automáticamente el token recién emitido como variable de entorno. Así, cada llamada al endpoint privado usa el token vigente sin pasos manuales [08:15].

¿Cuándo conviene RS256 sobre HS256? Usa RS256 cuando varios servicios necesitan verificar tokens sin compartir secretos. La llave pública puede distribuirse libremente; solo quien tiene la privada puede emitir tokens válidos.

¿Qué riesgos tiene exponer el secreto en HS256?

La diferencia entre ambos algoritmos no es solo técnica, también es de seguridad operativa.

• Con RS256, exponer la llave pública no es un problema. Su nombre lo dice: es pública y cualquier cliente o servidor puede usarla para verificar.
• Con HS256, el secret nunca debe ser expuesto. Quien lo tenga puede no solo verificar, también generar tokens nuevos, suplantar usuarios y comprometer todo el sistema.

La verificación, al final, es tan simple como regenerar la firma con el material correspondiente y compararla con la firma del token original. La complejidad real está en proteger las llaves.

¿Qué pasa si alguien obtiene mi secret HS256? Puede emitir tokens válidos a nombre de cualquier usuario. Por eso ese valor debe vivir solo en variables de entorno seguras y nunca en el código fuente ni en repositorios.

Como reto, replica el proceso de verificación en un lenguaje distinto a Node.js. Comparte en los comentarios qué librería elegiste y si te gustaría una introducción a criptografía para entender qué ocurre dentro de PKCS8 y los algoritmos de firma.