JSON Web Tokens | Qué es JWT? Explicación en 15 minutos sobre como tener un backend seguro

Nuevo vídeo en el que hoy vamos a hablar sobre los JSON web tokens, los cuales son importantísimos a la hora de crear microservicios.
Quiero pedir disculpas ya que tengo un nuevo setup, y al durante medio vídeo seguía mirando la pantalla antigua en lugar de donde tengo ahora la cámara.
Si te gusta el contenido, puedes apoyar al canal invitandome a un café www.buymeacoffee.com/netmentor
00:00 Introducción a Json web tokens
00:47 Qué son y para qué sirven los Json Web tokens
2:12 Qué es JWT
2:25 Historia de JWT
5:00 Partes de un Json web token con ejemplos
7:15 Diferencia entre autenticación y autorización
10:10 Qué es OAuth?
10:32 Qué es OAuth2?
11:30 Diferencia entre JWT y OAuth
14:45 JWT en microservicios
14:45 Pros y contras de JWT
17:30 Conclusión

[@NetMentor]

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...

[@CesarICAO]

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!!

[@clay9963]

algo que queria saber mucho, eres un crack

[@alexanderf.andrade9222]

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

[@boxeo18]

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

[@kervytmarrerorosales535]

Gracias ❤️

[@guillermosaez8094]

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

[@santiiza]

buena explicacion

[@andersonenocsmorilloguzman9139]

gracias amigoo

[@manuelvegauitz4411]

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]

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 !

[@Inyector]

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

[@gutixvideo]

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

[@land4bikers]

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

[@NetMentor]

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 😂😂

[@Pablo-Ramirez]

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]

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;

[@PabloHelal]

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

[@NetMentor]

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

[@user-rd4oo1jg5g]

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]

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

[@user-rd4oo1jg5g]

@@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?

[@inanesilence]

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]

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

[@programmingj613]

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

[@NetMentor]

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

[@nightwarriorFX]

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.

[@TheErudito]

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]

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

[@TheErudito]

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

[@luisandraschnik3001]

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!

[@marcoantoniotorreshernande5755]

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

[@NetMentor]

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

[@CragCode]

Alguna alternativa para jwt que no dependa de terceros?

[@NetMentor]

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