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

Implementando Resource Owner Password Grant

24/39

Lectura

Aplicaciones altamente confiables pueden usar este flujo, ya que en este flujo se le pregunta al usuario final llenar sus credenciales (usuario/contrase帽a) con un formulario interactivo y luego la informaci贸n es enviada al authorization server.

Usa este flujo solo si lo siguiente aplica:

  • Se le puede confiar absolutamente a la aplicaci贸n las credenciales del usuario. Para aplicaciones del lado del cliente o aplicaciones mobile se recomienda usar otros flujos.
  • Un flujo basado en redireccionamiento no es posible debido a que es una apliaci贸n legada. Si el redireccionamiento es posible se recomienda usar mejor Authorization Code Grant.

Conociendo el flujo

La definici贸n de Resource Owner Password Grant puede ser encontrada en https://tools.ietf.org/html/rfc6749#section-4.3.

  1. El usuario final ingresa sus credenciales en la aplicaci贸n (cliente) mediante un formulario.
  2. La aplicaci贸n env铆a las credenciales al Authorization Server.
  3. El Authorization Server valida las credenciales y devuelve un Access Token.
  4. La aplicacion ahora puede usar el Access Token para llamar la API en nombre del usuario.

Detalles de implementaci贸n

Para su implementaci贸n se debe implementar de parte de la aplicaci贸n un formulario que tome las credenciales del usuario y luego pueda hacer una petici贸n al Authorization Server. Es sumamente importante que esto suceda en una conexi贸n segura HTTPS.

  1. La aplicaci贸n obtiene las credenciales desde el formulario.
  2. La aplicaci贸n hace una petici贸n al Authorization Server.
const request = require("request");

const options = {
  method: "POST",
  url: "https://<authorization-server>/oauth/token",
  headers: { "content-type": "application/json" },
  body: {
    grant_type: "password",
    username: "<username>",
    password: "<password>",
    audience: "<your-audience>",
    scope: "<your-scopes>",
    client_id: "<your-client-id>",
    client_secret: "<your-client-secret>"
  },
  json: true
};

request(options, function(error, response, body) {
  if (error) {
    throw new Error(error);
  }
  console.log(body);
});
  1. La respuesta tiene un JSON Web Token, generalmente de tipo Bearer incluyendo el tiempo de expiraci贸n.
{
  "access_token": "eyJz93a...k4laUWw",
  "token_type": "Bearer",
  "expires_in": 36000
}
  1. La aplicaci贸n ya puede usar el JSON Web Token para hacer peticiones a los recursos del usuario (API) en nombre de 茅l.
const request = require("request");

const options = {
  method: "GET",
  url: "https://someapi.com/api",
  headers: {
    authorization: "Bearer <access-token>",
    "content-type": "application/json"
  }
};

request(options, function(error, response, body) {
  if (error) throw new Error(error);

  console.log(body);
});

Con esto tenemos los conocimientos necesarios para poder implementar este flujo. Recuerda seguir las recomendaciones para darle un uso adecuado.

Aportes 2

Preguntas 0

Ordenar por:

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

Pero si el token expira, 驴no ser铆a molesto estarle pidiendo el usuario y contrase帽a al usuario cada que expire?

Nueva pregunta:

驴Este flujo es el mismo que el Password Grant Tokens de Laravel? Laravel no lo maneja con el nombre de 鈥淩esource Owner Password Grant鈥 tal cual, pero por lo que veo, las definiciones son similares 馃

https://laravel.com/docs/8.x/passport#password-grant-tokens