Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

585
Views
¿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 answers
Answer question

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 Report

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 Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!