Descripción general de la solución (SPA + API)

Para garantizar que solo los usuarios y las aplicaciones autorizados puedan acceder a la API de Timesheets, ExampleCo ha decidido utilizar el marco de autorización de OAuth 2.0. Este marco ofrece la flexibilidad que la empresa busca, ya que los distintos tipos de concesión le permiten autorizar fácilmente los diversos tipos de aplicaciones que necesitan comunicarse con la API de Timesheets.

Autenticación y autorización de API

Una API es una forma de exponer la funcionalidad de su aplicación a otras aplicaciones. Una aplicación puede hacer una solicitud enviando un mensaje a un endpoint de una API y recibir información como respuesta. Un endpoint de API puede estar protegido o no. En nuestro caso, dado que los registros de horas son información confidencial que afecta a las revisiones y los pagos, es importante garantizar que solo los usuarios y las aplicaciones autorizados puedan llamar a los endpoints de nuestra API. Cuando una aplicación cliente quiere acceder a endpoints protegidos de una API, necesita presentar un como prueba de que tiene los permisos necesarios para llamar al endpoint. Un Token de acceso se obtiene autenticando al usuario con un , y el usuario puede luego autorizar a la aplicación para acceder a la API en su nombre.

¿Qué es un Token de acceso?

Un Token de acceso (también denominado access_token) es una cadena opaca que representa una autorización emitida para la aplicación. Puede indicar un identificador utilizado para recuperar la información de autorización o puede contener en sí mismo la información de autorización (por ejemplo, la identidad del usuario, los permisos, etc.) de forma verificable.Es bastante común que los Tokens de acceso se implementen como JSON Web Tokens.Para obtener más información sobre los Tokens de acceso de Auth0, consulte Token de acceso.

Una API puede aplicar un control detallado sobre quién puede acceder a los distintos endpoints expuestos por la API. Estos permisos se expresan como alcances. Cuando un usuario autoriza una aplicación cliente, la aplicación también puede indicar qué permisos requiere. A continuación, el usuario puede revisar y conceder estos permisos. Estos permisos se incluyen entonces en el Token de acceso como parte del claim scope. Posteriormente, cuando el cliente envía el Token de acceso al realizar solicitudes a la API, la API puede inspeccionar el claim scope para asegurarse de que se hayan concedido los permisos necesarios para llamar a ese endpoint de API en particular.

¿Qué son los Scopes?

Cada Token de acceso puede incluir una lista de los permisos que se han concedido al cliente. Cuando un cliente se autentica con Auth0, especificará la lista de alcances (o permisos) que solicita. Si esos alcances están autorizados, entonces el Token de acceso contendrá una lista de alcances autorizados.Por ejemplo, la API de registro de horas puede aceptar cuatro niveles diferentes de autorización: leer registros de horas (scope read:timesheets), crear registros de horas (scope create:timesheets), eliminar registros de horas (scope delete:timesheets) y aprobar registros de horas (scope approve:timesheets).Cuando un cliente solicita a la API crear una nueva entrada de registro de horas, el Token de acceso debe contener el scope create:timesheets. De forma similar, para eliminar registros de horas existentes, el Token de acceso debe contener el scope delete:timesheets.Para obtener más información sobre los alcances, consulte Scopes.

Al usar el marco de autorización , puede dar a sus propias aplicaciones o a aplicaciones de terceros acceso limitado a sus API en nombre de la propia aplicación. Con Auth0, puede admitir fácilmente distintos flujos en sus propias API sin preocuparse por la especificación OAuth 2.0/ Connect (OIDC) ni por los muchos otros aspectos técnicos de la autorización de API.

Roles de OAuth

En cualquier flujo de OAuth 2.0, podemos identificar los siguientes roles:

Propietario del recurso: la entidad que puede otorgar acceso a un recurso protegido. Normalmente, es el usuario final.
Servidor de recursos: el servidor que aloja los recursos protegidos. Es la API a la que quieres acceder.
Cliente: una aplicación que solicita acceso a un recurso protegido en nombre del propietario del recurso.
Servidor de autorización: el servidor que autentica al propietario del recurso y emite Tokens de acceso después de obtener la autorización adecuada. En este caso, la Authentication API de Auth0.

Los tipos de concesión (o flujos) determinan cómo interactúan estos participantes para conceder a las aplicaciones acceso limitado a las API que estás creando. Como resultado, la aplicación obtendrá un token de acceso que podrá usar para invocar la API en nombre del usuario.

Concesión implícita

OAuth 2.0 proporciona varios tipos de concesión para distintos casos de uso. En este caso concreto, queremos acceder a la API desde una aplicación del lado del cliente. La SPA usará el Flujo implícito (Concesión implícita) para hacerlo. La Concesión implícita (definida en RFC 6749, sección 4.1) es similar a la concesión utilizada en el Flujo de código de autorización, pero la principal diferencia es que la aplicación recibe un Token de acceso directamente, sin necesidad de un authorization_code. Esto ocurre porque la aplicación, que normalmente es una aplicación JavaScript que se ejecuta en un navegador, es menos fiable que una aplicación web que se ejecuta en el servidor y, por lo tanto, no puede considerarse de confianza para manejar el client_secret (que es obligatorio en la Concesión de código de autorización). Una vez que el usuario se autentica, la aplicación recibe el y el Token de acceso en el fragmento hash de la URI. La aplicación ya puede usar el ID Token para obtener información sobre el usuario y el Token de acceso para llamar a la API en nombre del usuario.

La aplicación inicia el flujo y redirige el navegador a Auth0 (concretamente al endpoint /authorize), para que el usuario pueda autenticarse.
Auth0 autentica al usuario. La primera vez que el usuario complete este flujo, y si la aplicación es de terceros, se mostrará una página de consentimiento en la que se enumeran los permisos que se otorgarán al cliente (por ejemplo, publicar mensajes, listar contactos, etc.).
Auth0 redirige al usuario a la aplicación con un Token de acceso (y, opcionalmente, un ID Token) en el fragmento hash de la URI. La aplicación ya puede extraer los tokens del fragmento hash.
La aplicación puede usar el Token de acceso para llamar a la API en nombre del usuario.

Authorization Extension

La Auth0 Authorization Extension permite configurar Roles, Groups y Permissions, y asignarlos a los usuarios.

Los Permissions son acciones que alguien puede realizar. Para las necesidades de negocio de ExampleCo, configuraremos cuatro Permissions: leer, crear, eliminar y aprobar registros de horas.
Los Roles son conjuntos de Permissions. La aplicación de registros de horas de ExampleCo será utilizada por dos tipos de usuarios (empleados y gerentes), cada uno con permisos diferentes, por lo que configuraremos dos Roles: empleado y gerente.

Como esto cubre nuestro caso de uso, no crearemos ningún Groups. Authorization Extension creará una Rule que leerá los Roles, Groups y Permissions asignados a un usuario y añadirá esta información al perfil de usuario durante el flujo de autenticación. Podemos usar esta información para garantizar que el Token de acceso emitido a un usuario solo contenga los alcances permitidos. Más adelante, podremos personalizar nuestra aplicación; por ejemplo, deshabilitar la funcionalidad para aprobar registros de horas si el usuario no tiene el permiso requerido para hacerlo.

​Autenticación y autorización de API