Bienvenida e introducci贸n

1

Qu茅 aprender谩s sobre autenticaci贸n con OAuth

2

Stack de seguridad para aplicaciones modernas

3

Autenticaci贸n

4

Autorizaci贸n

JSON Web Tokens

5

JSON Web Tokens

6

Autenticaci贸n tradicional vs JWT

7

Configuraci贸n inicial de los proyectos

8

Firmando un JWT

9

Verificando nuestro JWT firmado y buenas practicas con JWT

10

Server-Side vs Client-Side sessions

11

Protegiendo nuestros recursos con JWT

12

Habilitando CORS en nuestro servidor

13

Profundizando el concepto de JWKS

OAuth 2.0

14

C贸mo elegir el flujo adecuado para OAuth 2.0

15

驴Qu茅 es OAuth 2.0?

16

Conociendo el API de Spotify

17

Creando los clientes de Spotify y servicios iniciales

18

Implementando Authorization Code Grant

19

Usando nuestro access token para obtener nuestros recursos

20

Implementando Implicit Grant

21

Implementando nuestro servicio de autenticaci贸n

22

Modificando nuestro Layout

23

Implementando Client Credentials Grant

24

Implementando Resource Owner Password Grant

25

Implementando Authorization Code Grant (PKCE)

Open ID Connect

26

驴Qu茅 es OpenID Connect?

27

Implementando OpenID Connect

Preocupaciones con JWT y OAuth 2.0

28

驴Cu谩les son las preocupaciones con JWT?

29

驴Cu谩les son las preocupaciones con OAuth 2.0?

Haciendo uso de Auth0

30

驴Qu茅 es Auth0?

31

Auth0 Lock y auth0.js

32

Universal Login

33

Social Login con Auth0

34

Custom Social connection con Spotify

35

Multifactor authentication

36

Authorization Extension en Auth0

Consideraciones para producci贸n

37

Buenas pr谩cticas para el despliegue en producci贸n

38

Uso de diferentes tenants para producci贸n con Auth0

Cierre del curso

39

Cierre del curso

Autenticaci贸n tradicional vs JWT

6/39
Recursos

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 11

Preguntas 4

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesi贸n.

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 鈥渞obar鈥 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 鈥渞obar鈥 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.

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. 鉁岋笍

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.

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鈥