Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

587
Vistas
¿Cómo paso el JWT del servidor al cliente en un encabezado http?

No importa cuánto busqué la respuesta, no estoy satisfecho. En todas partes encuentro explicaciones sobre cómo pasar el token JWT del cliente al servidor, así como la forma más segura de hacerlo. Sin embargo, eso me molesta un poco. Quiero enviar el token JWT del cliente a este último a través de un encabezado HTTP, pero ¿cuál? Por lo que entiendo, esta es la forma más segura en lugar de usar una cookie.

Suponiendo que el usuario ya está registrado en mi base de datos. Envió el formulario de inicio de sesión al servidor, recuperé las credenciales y, a partir de ellas, generé un JWT. Ahora estoy usando express, ¿cómo enviar ese JWT al cliente en un encabezado?

estoy usando express en mi caso

 app.post("/login", async (inReq, inRes) => { //Loadin the user's database usersDB.loadDatabase((err)=>{ if (err) {console.log("Error while loading database: usersDB")}; }); // Our login logic starts here //We get the user's data const { username, password } = inReq.body; //We validate user input in some way. if(username.length < 4 || password.length < 8) return inRes.status(400).send('Bad data'); //and then we try to try { //Check if the user exists in our database const foundUser = await findUser(usersDB,{"username":username}); //Compare the two passwords (the one found in the DB and the one sent by our client) if (foundUser && (await bcrypt.compare(password, foundUser.password))) { //If evrything's fine we create token const token = await jwt.sign( { user_id: foundUser._id, username }, process.env.TOKEN_KEY, { expiresIn: "40s", }, function(err, intoken) { if(err) { console.log(err); return inRes.status(500).json({current_view: 'error', data: err}); } });

En ningún lugar

  • QUE HACER CON LA FICHA????
  • ¿QUÉ TÍTULO DEBO UTILIZAR? ¿Y cómo?
 // make a response to the user (successful login) return inRes.status(200).json(current_view: 'home', data: user); } //If the user is not valid we send an error return inRes.status(401).json(current_view: 'login', data: 'wrong-credentials'); } //We catch and log any error catch (err) { console.log(err); } // Our register logic ends here });
about 4 years ago · Juan Pablo Isaza
2 Respuestas
Responde la pregunta

0

También estoy en el mismo barco en este momento; como probablemente ya haya descubierto, no existe un consenso autorizado sobre cómo enviar el JWT al cliente. Las únicas reglas generales que he visto hasta ahora son de este enlace:

https://github.com/dwyl/hapi-auth-jwt2/issues/82#issuecomment-129873082

poner el token JWT en el encabezado de Autorización nos da flexibilidad para enviar una respuesta real en una aplicación web. Para una aplicación/API solo para REST, puede enviar el JWT como el cuerpo de respuesta o una cookie. Lo que importa es cómo el cliente almacena el JWT y lo envía de regreso al Servidor, lo cual se hace en el encabezado de Autorización (o Cookie o Token de URL si lo prefiere) 👍

En cuanto a esto que existe en el "salvaje", no he visto un ejemplo del servidor que envía un encabezado de Autorización al cliente, pero no hay nada en la especificación que sugiera que esto es un antipatrón. ver: http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html

Usando Express, he estado probando el envío del JWT a través del encabezado de Autorización:

 inRes.set('Authorization', `Bearer ${myJWT}`);

Haga esto antes de configurar inRes.status.

En el lado del cliente, las cosas parecen un poco más sencillas. Todo lo que he leído dice que no almacene el JWT en localStorage (si esa es una opción para usted) ya que no hay una propiedad de caducidad. Las cookies son solo un poco mejores porque se pueden configurar para que caduquen por fecha o por sesión, pero tienen la característica adicional de que se envían de vuelta al servidor con solicitudes futuras. En ese momento, sessionStorage es un potencial porque tiene un período de caducidad duro y rápido en el que solo duran hasta que se cierra el navegador.

Puede consultar esta sugerencia vinculada a continuación (aunque los ejemplos son específicos de Java, es más una explicación de propósito general) sobre cómo almacenar el JWT en el cliente:

https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.md#token-storage-on-client-side

about 4 years ago · Juan Pablo Isaza Denunciar

0

Gracias Scopique por tu respuesta. Sí, efectivamente entendí que la solución a este dilema no está sujeta a consenso. Además, mientras hablaba de eso, pasé por el mismo problema de gitHub que tú, jajaja. Creo que dado que la seguridad web está en juego, se debe incluir un enfoque seguro en la descripción de un estándar RFC.

Dado que actualmente no me preocupa el lado frontal, no pensé en cómo almacenar mi token. Sin embargo, esbocé este diagrama modesto. (Nota: ¡No estoy estipulando que esta sea la BUENA práctica!). es lo mejor que encontre por ahora ingrese la descripción de la imagen aquí

Sólo espero que no sea malo hacer cosas así. al menos por primera vez.

about 4 years ago · Juan Pablo Isaza Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda