Solución:
Los JWT pueden estar firmados, cifrados o ambos. Si un token está firmado, pero no encriptado, todos pueden leer su contenido, pero cuando no conoces el privado key, no puedes cambiarlo. De lo contrario, el receptor notará que la firma ya no coincidirá.
Respuesta a su comentario: No estoy seguro de haber entendido su comentario de la manera correcta. Solo para estar seguro: ¿conoce y comprende las firmas digitales? Explicaré brevemente una variante (HMAC, que es simétrica, pero hay muchas otras).
Supongamos que Alice quiere enviar un JWT a Bob. Ambos conocen un secreto compartido. Mallory no conoce ese secreto, pero quiere interferir y cambiar el JWT. Para evitar eso, Alice calcula Hash(payload + secret) y agrega esto como firma.
Al recibir el mensaje, Bob también puede calcular Hash(payload + secret) para comprobar si la firma coincide. Sin embargo, si Mallory cambia algo en el contenido, no puede calcular la firma coincidente (que sería Hash(newContent + secret)). Ella no conoce el secreto y no tiene forma de descubrirlo. Esto significa que si cambia algo, la firma ya no coincidirá y Bob simplemente ya no aceptará el JWT.
Supongamos que le mando el mensaje a otra persona "id":1 y firmarlo con Hash(content + secret). (+ es solo una concatenación aquí). Utilizo la función SHA256 Hash y la firma que obtengo es: 330e7b0775561c6e95797d4dd306a150046e239986f0a1373230fda0235bda8c. Ahora es tu turno: haz el papel de Mallory e intenta firmar el mensaje. "id":2. No puedes porque no sabes qué secreto usé. Si supongo que el destinatario conoce el secreto, PUEDE calcular la firma de cualquier mensaje y comprobar si es correcto.
Puedes ir a jwt.io, pega tu token y lee el contenido. Al principio, esto es discordante para mucha gente.
La respuesta corta es que JWT no se preocupa por el cifrado. Se preocupa por la validación. Es decir, siempre puede obtener la respuesta de “¿Se ha manipulado el contenido de este token”? Esto significa que la manipulación por parte del usuario del token JWT es inútil porque el servidor conocerá e ignorará el token. El servidor agrega una firma basada en la carga útil cuando emite un token al cliente. Más tarde, verifica la carga útil y la firma coincidente.
La pregunta lógica es ¿cuál es la motivación para no preocuparse por los contenidos cifrados?
-
La razón más simple es porque asume que este es un problema resuelto en su mayor parte. Si trata con un cliente como el navegador web, por ejemplo, puede almacenar los tokens JWT en una cookie que es
secure(no se transmite a través de HTTP, solo a través de HTTPS) yhttpOnly(no puede ser leído por Javascript) y habla con el servidor a través de un canal encriptado (HTTPS). Una vez que sepa que tiene un canal seguro entre el servidor y el cliente, puede intercambiar de forma segura JWT o cualquier otra cosa que desee. -
Esto mantiene las cosas simples. Una implementación simple facilita la adopción, pero también permite que cada capa haga lo que mejor hace (deje que HTTPS maneje el cifrado).
-
JWT no está destinado a almacenar datos confidenciales. Una vez que el servidor recibe el token JWT y lo valida, es libre de buscar el ID de usuario en su propia base de datos para obtener información adicional para ese usuario (como permisos, dirección postal, etc.). Esto mantiene el tamaño de JWT pequeño y evita la fuga de información involuntaria porque todos saben que no deben guardar datos confidenciales en JWT.
No es muy diferente de cómo funcionan las propias cookies. Las cookies suelen contener cargas útiles no cifradas. Si está utilizando HTTPS, entonces todo está bien. Si no es así, es recomendable encriptar las cookies confidenciales. No hacerlo significará que es posible un ataque man-in-the-middle: un servidor proxy o ISP lee las cookies y luego las reproduce fingiendo ser usted. Por razones similares, JWT siempre debe intercambiarse a través de una capa segura como HTTPS.
Discutamos desde el principio:
JWT es un enfoque muy moderno, simple y seguro que se extiende a los tokens web de Json. Los tokens web de Json son una solución sin estado para la autenticación. Por lo tanto, no es necesario almacenar ningún estado de sesión en el servidor, lo que, por supuesto, es perfecto para API tranquilas. Las API de descanso siempre deben ser sin estado, y la alternativa más utilizada a la autenticación con JWT es simplemente almacenar el estado de inicio de sesión del usuario en el servidor mediante sesiones. Pero, por supuesto, no sigue el principio que dice que las API tranquilas deben ser apátridas y es por eso que las soluciones como JWT se volvieron populares y efectivas.
Entonces, ahora sepamos cómo funciona realmente la autenticación con los tokens web de Json. Suponiendo que ya tenemos un usuario registrado en nuestra base de datos. Entonces, el cliente del usuario comienza haciendo una solicitud de publicación con el nombre de usuario y la contraseña, la aplicación luego verifica si el usuario existe y si la contraseña es correcta, la aplicación generará un token web Json único solo para ese usuario.
El token se crea utilizando un secreto string es decir almacenado en un servidor. A continuación, el servidor envía ese JWT al cliente, que lo almacenará en una cookie o en un almacenamiento local.
Así, el usuario se autentica y básicamente inicia sesión en nuestra aplicación sin dejar ningún estado en el servidor.
Entonces, el servidor de hecho no sabe qué usuario está realmente conectado, pero, por supuesto, el usuario sabe que ha iniciado sesión porque tiene un Json Web Token válido, que es un poco como un pasaporte para acceder a partes protegidas de la aplicación.
Así que de nuevo, solo para asegurarnos de que entendiste la idea. Un usuario inicia sesión tan pronto como recupera su token web Json válido único que no se guarda en ningún lugar del servidor. Por tanto, este proceso es completamente apátrida.
Luego, cada vez que un usuario quiera acceder a una ruta protegida como los datos de su perfil de usuario, por ejemplo. Envía su Json Web Token junto con una solicitud, por lo que es un poco como mostrar su pasaporte para acceder a esa ruta.
Una vez que la solicitud llega al servidor, nuestra aplicación verificará si el Json Web Token es realmente válido y si el usuario es realmente quien dice ser, entonces los datos solicitados se enviarán al cliente y si no, entonces habrá ser un error al decirle al usuario que no tiene permiso para acceder a ese recurso.
Toda esta comunicación debe realizarse a través de https, por lo que Http cifrado seguro para evitar que cualquier persona pueda acceder a contraseñas o tokens web Json. Solo entonces tendremos un sistema realmente seguro.
Entonces, un Json Web Token parece la parte izquierda de esta captura de pantalla que fue tomada del depurador de JWT en jwt.io. Básicamente, es una codificación string compuesto por tres partes. El encabezado, la carga útil y la firma Ahora, el encabezado es solo algunos metadatos sobre el token en sí y la carga útil son los datos que podemos codificar en el token, cualquier dato que realmente queramos. Entonces, cuantos más datos queramos codificar aquí, mayor será el JWT. De todos modos, estas dos partes son solo texto sin formato que se codificará, pero no se cifrará.
Para que cualquiera pueda decodificarlos y leerlos., no podemos almacenar ningún dato sensible aquí. Pero eso no es un problema en absoluto porque en la tercera parte, así que en la firma, es donde las cosas se ponen realmente interesantes. La firma se crea utilizando el encabezado, la carga útil y el secreto que se guarda en el servidor.
Y todo este proceso se llama firmando el Json Web Token. El algoritmo de firma toma el encabezado, la carga útil y el secreto para crear una firma única. Entonces, solo estos datos más el secreto pueden crear esta firma, ¿de acuerdo? Luego, junto con el encabezado y la carga útil, estas firmas forman el JWT, que luego se envía al cliente.
Una vez que el servidor recibe un JWT para otorgar acceso a una ruta protegida, necesita verificarlo para determinar si el usuario realmente es quien dice ser. En otras palabras, verificará si nadie cambió el encabezado y los datos de carga útil del token. Entonces, nuevamente, este paso de verificación verificará si ningún tercero realmente alteró el encabezado o la carga útil del Json Web Token.
Entonces, ¿cómo funciona realmente esta verificación? Bueno, en realidad es bastante sencillo. Una vez que se recibe el JWT, la verificación tomará su encabezado y carga útil, y junto con el secreto que aún está guardado en el servidor, básicamente creará una firma de prueba.
Pero la firma original que se generó cuando se creó por primera vez el JWT todavía está en el token, ¿verdad? Y esa es la key a esta verificación. Porque ahora todo lo que tenemos que hacer es comparar la firma de prueba con la firma original. Y si la firma de prueba es la misma que la firma original, significa que la carga útil y el encabezado no se han modificado.
Porque si se hubieran modificado, entonces la firma de prueba tendría que ser diferente. Por lo tanto, en este caso en el que no ha habido alteración de los datos, podemos autenticar al usuario. Y, por supuesto, si las dos firmas son realmente diferentes, bueno, entonces significa que alguien manipuló los datos. Por lo general, al intentar cambiar la carga útil. Pero ese tercero que manipula la carga útil, por supuesto, no tiene acceso al secreto, por lo que no puede firmar el JWT. Por lo que la firma original nunca corresponderá a los datos manipulados. Y por lo tanto, la verificación siempre fallará en este caso. Y esa es la key para hacer que todo este sistema funcione. Es la magia lo que hace que JWT sea tan simple, pero también extremadamente poderoso.
Te mostramos las comentarios y valoraciones de los lectores
Acuérdate de que te damos el privilegio aclarar si te ayudó.