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

A煤n no tienes acceso a esta clase

Crea una cuenta y contin煤a viendo este curso

Server-Side vs Client-Side sessions

10/39
Recursos

Autenticar usuarios desde de lado del servidor es considerado stateful, debemos utilizar sesiones para preservar los estados de autenticaci贸n, es decir, guardamos en memoria o en una base de datos un identificador que nos permita comprobar si los usuarios est谩n o no autenticados.

Por otro lado, la autenticaci贸n de lado del cliente no utiliza sesiones, en realidad, no tenemos forma de verificar si los usuarios est谩n autenticados o no, en vez de esto, validamos los datos de usuario para obtener tokens (con l铆mite de tiempo) que utilizamos en las peticiones al servidor para validar el acceso y consultar nuestra informaci贸n.

Proceso de autenticaci贸n de lado del cliente:

  1. Cuando los usuarios hacen login, el servidor responde con un token (indicando que el login fue exitoso) y nosotros, de lado del cliente, agregamos una bandera para indicar que el usuario esta autenticado.
  2. En cualquier punto de nuestra aplicaci贸n (por ejemplo, cuando cambiamos de ruta o hacemos una nueva petici贸n) debemos verificar la expiraci贸n de los tokens.
  3. Si el token expira, debemos cambiar la bandera para indicar que el usuario NO esta autenticado y nuevamente redireccionar a los usuarios a la ruta de login.

Aportes 5

Preguntas 2

Ordenar por:

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

Notas de la clase:

  • Las sesiones del lado del servidor funcionan almacenando un indicador en memoria o en la base de datos, cuando este indicador desaparece, significa que el usuario ya NO esta autenticado 馃憤
  • Estos indicadores viajan (normalmente) a trav茅s de cookies, el servidor lo envia al navegador y el navegador lo env铆a de vuelta al servidor 馃攤
  • Del lado del cliente NO utilizamos sesiones 馃槷
  • En Single Page Applications NO tenemos forma de verificar la autenticaci贸n de los usuarios, tendr铆amos que refrescar la p谩gina cada vez que necesitamos nueva informaci贸n y b谩sicamente se pierde el chiste, as铆 no funcionan estas aplicaciones 馃槮
  • En vez de sesiones utilizamos tokens, enviamos los datos de autenticaci贸n de nuestros usuarios al servidor y, si los datos son correctos, el servidor devuelve un token, una llave que nos da acceso por alg煤n tiempo a la informaci贸n autorizada de los usuarios 馃帀馃憣
  • Si en alguna de las peticiones al servidor nos informan que el token ha expirado pos, volvemos a hacer login y seguimos como si nada 馃槄馃挭

PLatzi usa Web tokens??

Esto lo veo m谩s como para un sistema de autenticaci贸n de un banco, porque ser铆a realmente algo malo estarle mostrando cada 15 minutos un mensaje al usuario de 鈥淪u sesi贸n ha expirado鈥, imagino que para este caso se usan otras cosas como los Personal Acess Token 馃

驴No hay forma de refrescar el token? En la forma tradicional expiramos una sesi贸n cuando hay inactividad en el uso de la app. Pero con jwt estamos estableciendo que el token expira en un tiempo determinado sin importar si hay actividad en la navegaci贸n de nuestra aplicaci贸n, por lo que si el usuario esta gestionando algo, al pasar el tiempo, se expirar谩 su autenticaci贸n.

buena explicaci贸n.