Saltar al contenido principal
Para garantizar que solo los usuarios y las aplicaciones autorizados puedan acceder a la API de registros de horas, ExampleCo ha decidido utilizar el framework de autorización OAuth 2.0. Este framework 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 registros de horas.

​
OAuth 2.0

Al usar el marco de autorización , la aplicación web tradicional de ExampleCo y la aplicación de terceros para contratistas externos pueden tener acceso limitado a la API de registros de horas. Con Auth0, ExampleCo puede admitir fácilmente distintos tipos de concesión o flujos de autenticación sin tener que preocuparse por la especificación OAuth 2.0/ Connect (OIDC) ni por muchos de los demás aspectos técnicos de la autorización de API.

Roles de OAuth

En cualquier flujo de OAuth 2.0, podemos identificar los siguientes roles:
  • Resource Owner: la entidad que puede conceder acceso a un recurso protegido. Normalmente, es el usuario final.
  • Resource Server: el servidor que aloja los recursos protegidos. Es la API a la que se quiere acceder.
  • Client: una aplicación que solicita acceso a un recurso protegido en nombre del Resource Owner.
  • Authorization Server: el servidor que autentica al Resource Owner 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 otorgar a las aplicaciones acceso limitado a las API que está creando. Como resultado, la aplicación obtendrá un token de acceso que puede usarse para llamar a la API en nombre del usuario.

​
Concesión de credenciales de cliente

OAuth 2 proporciona varios tipos de concesión para diferentes casos de uso. En este caso concreto, en el que una tarea cron subirá registros de horas a través de una API, no hay ningún usuario interactivo (ni un ) que pueda conceder permisos a la tarea cron para acceder a la API. La tarea cron tampoco realiza llamadas a la API en nombre de ningún usuario. En su lugar, la aplicación (la tarea cron) usa autorización de máquina a máquina y realiza llamadas al (la API) en nombre propio. Para situaciones como esta, en las que no hay interacción del usuario, la Concesión de credenciales de cliente es ideal. Con la Concesión de credenciales de cliente (definida en RFC 6749, sección 4.4), una aplicación puede solicitar directamente un al mediante sus credenciales de cliente (un y un ). En lugar de identificar a un propietario del recurso, este token representará a la propia aplicación.
undefined
  1. La aplicación se autentica ante el Servidor de autorización con su ID de cliente y su Secreto del cliente.
  2. El Servidor de autorización valida esta información y devuelve un token de acceso.
  3. La aplicación puede usar el token de acceso para llamar al Servidor de recursos en nombre propio.

​
Autenticación y autorización de API

Una API es una forma de exponer la funcionalidad de tu aplicación a otras aplicaciones. Otras aplicaciones pueden hacer una solicitud a un endpoint de la API y recibir una respuesta. Del mismo modo, la aplicación externa que usan los contratistas de ExampleCo puede comunicarse con la API de registro de horas, así como con la aplicación web regular que ExampleCo creó para los empleados internos. Dado que la API de registro de horas maneja información confidencial (como PII e información financiera), ExampleCo debe asegurarse de que solo los usuarios y las aplicaciones autorizados puedan llamar a sus endpoints.

​
Tokens de acceso y alcances

Las API pueden estar protegidas o no. Cuando una aplicación quiere acceder a endpoints protegidos de una API, debe proporcionar un token de acceso (también denominado access_token) como prueba de que tiene los permisos necesarios. Un token de acceso es una cadena opaca que representa una autorización concedida a la aplicación y se obtiene autenticando al usuario ante un Servidor de autorización. A su vez, el usuario puede autorizar a la aplicación para que acceda a la API en su nombre. Para obtener más información, consulte Tokens de acceso. Una API como la API de registros de horas puede aplicar un control granular sobre quién puede acceder a los distintos endpoints que expone. Estos permisos se expresan como alcances. Cuando la aplicación web regular de ExampleCo o la aplicación de terceros se autentica con Auth0 para obtener un token de acceso, la solicitud de autenticación incluye la lista de alcances solicitados que necesita la aplicación. Si esos alcances están permitidos, el token de acceso contendrá una lista de alcances autorizados concedidos a la aplicación. La aplicación web regular o la aplicación de terceros incluye el token de acceso del Servidor de autorización al realizar solicitudes a la API de registros de horas, y la API de registros de horas inspecciona el claim scope para garantizar que se concedieron los permisos requeridos para llamar a ese endpoint en particular. Por ejemplo, la API de registros 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). Para obtener más información sobre los alcances, consulte Alcances. Cuando la aplicación web regular envía una solicitud a la API de registros de horas para crear una nueva entrada de registro de horas, el token de acceso debe contener el scope create:timesheets; de lo contrario, la solicitud será denegada. 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, consulte Alcances.