IMPORTANTE: Las cookies no se llaman como se llaman por las galletas esas adictivas de navidad con chispas de chocolate y sabores deliciosos. NO. Su nombre viene de las galletas de la fortuna que tienen un mensaje adentro intentando adivinar tu futuro, algo más parecido a la funcionalidad de las cookies en la comunicación de servidores y navegadores. #Epic. ✌️
Bienvenida e introducción
Qué aprenderás sobre autenticación con OAuth
Stack de seguridad para aplicaciones modernas
Autenticación
Autorización
JSON Web Tokens
JSON Web Tokens
Autenticación tradicional vs JWT
Configuración inicial de los proyectos
Firmando un JWT
Verificando nuestro JWT firmado y buenas practicas con JWT
Server-Side vs Client-Side sessions
Protegiendo nuestros recursos con JWT
Habilitando CORS en nuestro servidor
Profundizando el concepto de JWKS
OAuth 2.0
Cómo elegir el flujo adecuado para OAuth 2.0
¿Qué es OAuth 2.0?
Conociendo el API de Spotify
Creando los clientes de Spotify y servicios iniciales
Implementando Authorization Code Grant
Usando nuestro access token para obtener nuestros recursos
Implementando Implicit Grant
Implementando nuestro servicio de autenticación
Modificando nuestro Layout
Implementando Client Credentials Grant
Implementando Resource Owner Password Grant
Implementando Authorization Code Grant (PKCE)
Open ID Connect
¿Qué es OpenID Connect?
Implementando OpenID Connect
Preocupaciones con JWT y OAuth 2.0
¿Cuáles son las preocupaciones con JWT?
¿Cuáles son las preocupaciones con OAuth 2.0?
Haciendo uso de Auth0
¿Qué es Auth0?
Auth0 Lock y auth0.js
Universal Login
Social Login con Auth0
Custom Social connection con Spotify
Multifactor authentication
Authorization Extension en Auth0
Consideraciones para producción
Buenas prácticas para el despliegue en producción
Uso de diferentes tenants para producción con Auth0
Cierre del curso
Cierre del curso
Crea una cuenta o inicia sesión
¡Continúa aprendiendo sin ningún costo! Únete y comienza a potenciar tu carrera
Autenticación tradicional vs JWT
6/39Recursos
La autenticación tradicional funciona creando un espacio en memoria con un id para identificar a los usuarios activos, estos IDs se almacenan en cookies (información que enviamos o modificamos entre servidores y navegadores) para identificar si los usuarios están o no autenticados. Todas las cookies tienen un tiempo límite, es decir, después de cierto tiempo la cookie se borra y la sesión termina, el usuario debe volver a autenticarse.
El problema de este tipo de autenticación es que no funciona con _Single Page Applications (aplicaciones construidas sobre una única página), ya que no refrescamos el navegador para acceder a nueva información o verificar la autenticación de los usuarios, no hay forma de acceder a las cookies a medida que los usuarios interactúan con la aplicación. También tenemos problemas cuando construimos aplicaciones con arquitecturas basadas en microservicios, cualquier control de permisos requiere volver a realizar peticiones en la base de datos.
La autenticación con tokens funciona generando tokens con la identificación y los permisos de cada usuario, estos tokens son enviados y almacenados desde el cliente, así que, siempre que nuestras aplicaciones necesitan verificar los permisos de los usuarios simplemente necesitan validar los tokens. Gracias a este tipo de autenticación NO necesitamos un servicio de backend para almacenar las sesiones de autenticación de los usuarios, solo con guardar y validar los tokens podemos controlar los permisos para cada usuario.
Aportes 13
Preguntas 5
Ordenar por:
Más adelante, en la clase Firmando un JWT, vamos a ver mucho mejor (con un ejemplo práctico) cómo crear un JWT y cómo funciona su validación 👌.
Resumiendo un poco, toda la información que viaja en el token (lo que va adentro del header y del payload) es completamente visible para cualquier persona que acceda al token 😳😱 (podemos probar copiando y pegando uno en el debugger de https://jwt.io 😮). Cualquier usuario, bueno o malo, mortal o máquina, puede ver y “robar” la información delicada que se encuentre por ahí. El chiste de los tokens es que el servidor NO les permite realizar ninguna acción si cambian el contenido del token, es decir, aunque podemos “robar” la información del token, no podemos ejecutar ninguna acción del servidor a menos que tengamos las llaves secretas 😌.
Aún más resumido lo entienden en esta parte de la clase de más adelante (los últimos minutos): https://platzi.com/clases/1439-autenticacion-oauth/15812-firmando-un-jwt/?time=851.
Que interesante el origen del nombre de la cookie! jeje
Por eso anteriormente era mucho más fácil autenticarse como otra persona en servicios de mensajería como messenger en su época. xD
Lo que no pillo es, con tu token tienes que hacer una peticion al servidor para que te verifique si es valido igual no? entonces el proceso no es el mismo k con la cookie? lo unico que cambia es que no tienes un campo en la bd con la sesion, xk simplemente lo sacas con el secret y el token, pero la peticion a backend la haces igual.
Ademas las SPA tienen estado, via redux u otros, asi que cuando el servidor resolviera, si no hay permisos puede actualizar el contenido en cualquier momento.
Muchas gracias.
Süper interesante!!
Muy buena explicación
buena ilusracion entre json y token tradicional
Excelente comparativa. Muy claro en concepto.
Me parece interesante lo que dijo, que si ya enviar el token, podemos confiar que todo esta bien! Veamos cómo es esto!
Entonces si quiero terminar con la sesión como funciona??
Las paginas single page si hacen request al servidor…
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?