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
JSON Web Tokens
5/39Recursos
Los JSON Web Tokens (JWT) son un estándar que nos permite representar los permisos o requerimientos entre dos partes, es decir, el servidor de nuestra aplicación concede los permisos para un usuario generando un token, este token se envía al cliente o navegador donde utilizamos el token para realizar peticiones al servidor sin que éste necesite verificar a los usuarios, simplemente recibe los JWT y devuelve la información a la que el usuario tiene permiso según cada token.
Los JWT se dividen en 3 cadenas de texto separadas por puntos. La primera parte es el header y contiene el algoritmo y el tipo de token que utilizamos para firmar. La segunda parte es el payload, contiene información como la identificación del usuario, fechas de creación y expiración del token, entre otras ( debemos tener cuidado de no transmitir información sensible ya que, puede ser decodificada por alguna otra aplicación). Por último, la signature es la tercera parte del token y se genera codificando los anteriores campos más una firma secreta, gracias a esta parte del token podemos verificar su autenticidad e invalidar el token si alguno de los campos cambia.
Podemos utilizar dos tipos de algoritmos para codificar nuestros tokens, los simétricos nos permiten encriptar y desencriptar los tokens utilizando una única llave privada, o podemos utilizar algoritmos asimétricos que utilizan una llave privada y una publica para tener mayor seguridad y evitar problemas si alguna de las llaves es interceptada.
Aportes 23
Preguntas 3
Ordenar por:
¿Cuál es la diferencia entre los términos “codificación”, “encriptación” y “hash”?
Resumen
Estructura JWT
- header: Contiene algoritmo y tipo de token
- payload: Contiene información
- signature: Es una firma encriptada generalmente en sha-256
Header y payload vienen codificados en base64
Algoritmos simétricos usan una unica llave
Algoritmos asimétricos usan dos llaves una publica y otra privada
Dejo por acá un interesante artículo sobre los JWT!
Cuando @glrodasz explica los JWT entre dos partes (0:13 - 0:49), se refiere al cliente y al servidor.
La parte que genera el JWT, es el servidor, concediéndole varios permisos (peticiones).
La segunda parte se trata del cliente, que utiliza el JWT generado por el server para que el cliente pueda hacerle peticiones al server.
Wow, me parece un método super inteligente de verificar los tokens, es decir, básicamente la signature es la que ya tiene todo el contenido pero firmado con una especie de contraseña, entonces al decodificar el contenido “payload” con el signature, se da cuenta que no es lo mismo y acaba dando una respuesta inválida de que la firma no es segura!
siempre este tema es motivo para molestar a los que se llaman jeison jason, jaison, yeisson etc.
¿Existen escenarios donde tenga sentido encriptar un token?
super, mil gracias por la explicación
El JWT puede ser facilmente leido y manipulado pero la firma asegura que no nos cambien la infromación.
Los yo Web Tokens UwU
Los tokens de acceso se utilizan en la autenticación basada en tokens para permitir que una aplicación acceda a una API. La aplicación recibe un token de acceso después de que un usuario autentica y autoriza el acceso con éxito, luego pasa el token de acceso como una credencial cuando llama a la API de destino. El token pasado informa a la API que el portador del token ha sido autorizado para acceder a la API y realizar acciones específicas especificadas por el alcance otorgado durante la autorización.
son seguros los jwt?
en el minuto 05:54 el profe se confunde, en realidad, al firmar los JWT con un secret es lo que puede caer en manos equivocadas, para el caso del algoritmo asimétrico intuyo que la expresión no esta acorde
El recurso keygen ya no se encuentra disponible.
Gran explicación, me quedo claro JWT
JWT es un estadar RFC 7519 para autenticacion de usuarios
JSON WEB TOKEN esta codificado y no cifrado, comprende 3 partes, Header,Payload y Signature
a estudiar Json Web Tokens
Codificación/Decodificación: Es un proceso reversible. (ie: base64)
Se recomienda usa una cadena de 256 bits para la calve secreta
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?