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

¿Qué es OAuth 2.0?

15/39

Lectura

¡Un saludo, Platzinauta!👋🏻

¡Ups! De momento, esta clase no está disponible en nuestra plataforma, pero sí la tenemos en YouTube.

Para no interrumpir tu aprendizaje te dejamos el video y link para que puedas verla en YouTube.

Link a YouTube

Pronto estará disponible en Platzi como el resto de clases.

Gracias por tu comprensión y nunca pares de aprender💚

Aportes 21

Preguntas 3

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

Es excelente hasta ahora este curso. La explicacion es muy clara de todos los conceptos, y ademas con ejemplos adicionales de la vida real para bajar aun mas a tierra los conceptos aprendidos. 👏👏

Si alguien me puede corregir se lo agradecería.

  • Le pido el favor a mi hija que vaya a mi apartamento y recoja mi portátil, le doy mi cédula para que ella se la presente al celador del edificio y el le entregue las laves del apartamento
  • Ella llega a la portería y presenta mi cédula indicando que viene en nombre mio a recoger las llaves del apartamento
  • EL celador verifica que la cédula es correcta y le entrega las llaves a mi hija
  • Es correcta mi analogía? o me falta algo

OAuth2 es un protocolo de autorización, que surgió a partir del nacimiento de la Web Social. Permite que los usuarios autoricen a terceros a acceder a su información sin que estos tengan que conocer las credenciales del usuario.

Hay múltiples entidades involucradas en el flujo de OAuth2:

Propietario de recursos: Parte que puede autorizar el acceso a los recursos protegidos. Puede ser una autorización de ciertos recursos y de otros no. Generalmente es una persona.
Cliente: Es el sitio web o aplicación que accederá a los recursos protegidos de un usuario con la autorización del mismo
Proveedor:
Servidor de autorización: Valida usuario y credenciales; y genera tokens de acceso.
Servidor de recursos: Recibe peticiones de acceso a los recursos protegidos autorizando acceso si el token que viene (en el cuerpo o en las cabeceras, generalmente en las cabeceras) en la petición es válido.

esto me suena similar al curso de API REST, autenticacion con Acces Token en donde interfieren siempre 3 actores el cliente, el servidor de autenticacion, y el servidor donde se solicitan los recursos esto es cierto?

Muy clara la explicación 😄

Creo que falta hablar cuando nuestra aplicación genera el toquen o autorización. Seria como si el de las llaves fuera la hermana y el hermano pequeño le pide el recurso y la hermana le da las llaves. No he visto aun el manejo adecuado que se le hace si no usamos OAuth 2.0, cual es la forma adecuada de guardar el JWT, tal vez más adelantan del curso lo muestre,

Hola a todos. Únicamente comentaros que el capítulo "¿Qué es OAuth2?" es el mismo que "Conociendo la API de Spotify", para que lo corrijáis cuándo tengáis un hueco. Saludos!.

De que forma el resource owner puede verificar que la aplicación es quien dice ser?

Buena explicacion, muy clara y precisa.

una explicacion my clara de OAuth 2.0

excelente la explicación de la vida real

Quedo muy claro con el ejemplo.

jajajaj que excelente ejemplo.

No había entendido del todo el funcionamiento, pero con el ejemplo de la pelota y de la aplicación pidiendo permisos para acceder a nuestros recursos, lo entendí del todo.

Este video se muestra mal en mobile. Me aparece el de la API de Spotify!

El ejemplo de la familia es GENIAL!! me ha quedado más claro.

OAuth: sirve pra la autorización

  1. El cliente pregunta a dueño del recurso autorización
  2. El cliente con la autorización solicita al servidor de autorización las llaves
  3. El cliente con la llaves accede al servidor de recursos

El servidor de autorización crea llaves temporales.
Las llaves temporales sirven para acceder a los recursos.

  1. Client ask to Resource Owner Authorization
  2. Client With Authorization request to Authorization Server the keys
  3. Client With keys access to Resource Server Assets

Excelente ejemplo, la vida real es algo muy chevere para darle sentido a las cosas!

Comprendo, aunque veo que la validación del token lo hace el servidor de API, pensaba que el servidor de API tenía que hacer una solicitud hacia el authentication server para verificar si el token existía en la base de datos

Por lo que veo ahora, con este flujo de autenticación ni siquiera es necesario guardar un token en la base de datos porque tanto el authorization como el API server conocen la llave secreta y puede decodificar dicho token

Básicamente el authorization firma el token con la llave secreta y el API usa la misma llave para verificar que la firma es verdadera!