wow muy buena explicación, me recordó a las clases de la universidad, ultimamente solo hay explicaciones en youtube donde son muy superficiales, pero tu explicas muy bien y a profundidad, aunque sea introductorio. Muchas gracias por compartir y por la dedicación. Soy front pero quiero entender bien el transfondo de los JWTs. Saludos desde México!!

Gran contenido, la verdad que vendría genial que en el curso de web api que estas haciendo incluyeras un ejemplo con jwt e identity porque la verdad explicas muy bien todo estos temas y casi no hay contenido al respecto, muchas gracias, saludos

Blog: www.netmentor.es/Entrada/que-es-jwt Twitter twitter.com/NetMentorTW Edit: me refiero a xss (Cross site scripting) no se en que estaría pensando cuando he mencionado cfrs...

Me ha encantado la parte de la pistola en la cabeza y "¡En el header!"

Muchas gracias por compartir tu conocimiento, si no es mucho pedir podrías subir un ejemplo de la implementación del token de refresco

@NetMentor

3 жыл бұрын

Hola! Si, quiero subir un vídeo con lo que sería la implementación completa (token normal y de refresco) pero será en enero probablemente, un saludo !

buena explicacion

Excelente explicación, un suscriptor más ;)

algo que queria saber mucho, eres un crack

gracias amigoo

Gracias ❤️

Excelente video , tienes algún ejemplo aplicando el refresh token?

Muchas gracias por compartir conocimiento, Tienes video de la implementación?

@NetMentor

2 жыл бұрын

Hola no, no tengo implemtación, es uno de esos vídeos que tengo pendientes, pero es taaaaan aburrido, que siempre lo voy empujando mas abajo en la lista 😂😂

Buena explicación. Dónde puedo ver un ejemplo real de implementación?

Muy buen video.Consulta, hablando del JWT, tengo que internamente almacenar en mi bbdd el token y refresh para saber cuando volver a solicitarlo? Muchas gracias

@NetMentor

11 ай бұрын

no, se almacenan en el cliente, y es el cliente el que tiene que hacer dicha comprobación

@user-rd4oo1jg5g

11 ай бұрын

@@NetMentor muchas gracias. supongamos que yo tengo una app interna con servicios pero uso un unico usuario para hacer los llamados a las apis independientemente de que sean distintos clientes, no se debe almacenar?

A qué te refieres con CFRS? Gracias por el video.

@NetMentor

3 жыл бұрын

:facepalm: me refiero al Cross site scripting osea xss fallo mío

Muchas gracias por tu video y por este interesante tema. Solo una consulta, si el token tiene un Id cuando se crea, con ese mismo Id se podría eliminar, en caso de un robo o hackeo?

@NetMentor

2 жыл бұрын

técnicamente si, puedes ponerle una propiedad ID y luego en la pipeline de la validación (a través de un middleware) validar que ese Id es válido;

Tengo una duda q el el login obtengo el token pero tiene una caducidad de 15 minutos una vez caducado el bearer ya no funciona segun he leido usar refresh token pero no puedo aun

@NetMentor

5 ай бұрын

si, tienes que utilizar el refresh token para recibir un token nuevo

@TheErudito

5 ай бұрын

@@NetMentor para cuando un tuto de eso seria de gran ayuda estoy estancado alli

En el IdentityProvider entiendo que tendrá que cotejarse (con el típico email y password) con unos datos en DB, no? Por otra parte, sería ese el sitio adecuado para tener almacenados los roles de determinado usuario? Gran explicación!

@NetMentor

11 ай бұрын

Si y no, puedes tener solo la autenticación en el identity provider y la autorización una custom en tu sitio, o ambas en el identity provider, eso ya depende de cada empresa. Y luego si, el idp contiene el usuario y la contraseña, pero solo se cotejan para generar el token, una vez está generado, ya no se comprueban

Y en caso que quiera hacer un logout que conviene usar?

@NetMentor

3 жыл бұрын

Como logout normal nada, simplemente "quitarlo del cliente" pero seguirá siendo válido hasta su tiempo de expiración, no se puede hacer logout como en las sesiones por ejemplo

Hola! Tengo que realizar transferencias de información desde un aplicación web de un ERP (Tryton) contra un API de un portal web que se autentica por JWT, miles de requests, y estoy solicitando el token (vence en 3600 segundos) en cada request, sin guardar el token en ninguna variable. Estuve leyendo y parece que hay mucha controversia, algunos consideran que es mala práctica cachear el token ya sea guardarlo en memoria, en un archivo y reutilizarlo porque eso sería generar un estado o session, cuando el método es stateless, además de riesgos de seguridad de tipo CSRF, etc. En todo caso para guardar ese token debería generarlo fuera de la función que hace el request y pasarlo como argumento? Actualmente metí el pedido del token directamente dentro de la misma función que hace el request y me desentiendo de verificar si el toquen está vencido, ya que cada request tardará un segundo, pero no tengo idea de cuanto overhead estoy causando. Sdos

@NetMentor

Жыл бұрын

En este caso deberías almacenar el token, y más si son miles de llamadas. En el token puedes comprobar cuanto le queda y si está en el último minuto refrescar lo (busca refresh token en Google). Pero en tu caso por lo que comentas deberías almacenar el token, no es mi mismo una llamada por minuto o cada diez que miles, imagina cada servicio haciendo lo mismo, en idp explotaría; y si pagas por el, os costará dinero también. Yo personalmente haría un wrapper o in servicio que mantenga el token en memoria y reutilizarlo cuando puedas. Un saludo !

@luisandraschnik3001

Жыл бұрын

@@NetMentor Ahh, no tenía en cuenta que le puedo estar haciendo pagar a mi colega por cada pedido de token. Suerte que recién estamos haciendo pruebas de integración entre sistemas, y esta utilidad apenas empezó, es buen momento para mejorar la lógica. No soy un programador experto, ni siquiera vengo del rubro porque soy Técnico Químico, Lic en Organización Industrial y Especialista en Higiene y Seguridad laboral, sólo soy un autodidacta entusiasta de la programación y a los 54 años esta actividad está dando una segunda vida a mi trabajo y es lo único que me permite estar a la par de mis compañeros de trabajo que es gente con un enorme know how del core del negocio. Muchas gracias por el consejo, sdos desde Argentina!

en una parte indicas que esta CIFRADA y NO ENCRIPTADA, en realidad ahi debería haber dicho esta CODIFICADA, porque CIFRADA Y ENCRIPTADA son sinónimos.

Alguna alternativa para jwt que no dependa de terceros?

@NetMentor

2 жыл бұрын

A que te refieres exactamente? por poder puedes crear tu propio servicio que te devuelva un JWT válido. pero basandome en mi experiencia trae menos problemas a la larga utilziar un servicio externo para administrar los usuarios

cuando creo un token me dice que es invalido al verificarlo :(

@NetMentor

2 жыл бұрын

no te dice nada mas? lo estas validando contra el mismo sistema que lo creo? Un saludo