Saltar al contenido principal
Como desarrollador de una API, debe hacer lo siguiente:
  1. Decidir a qué información quiere que las aplicaciones puedan acceder en nombre de un usuario.
  2. Definir estos niveles de acceso como alcances personalizados. (Para saber qué son los alcances, consulte alcances.)
  3. Identificar estos alcances para que las aplicaciones que llaman a la API puedan usarlos.

​
Formas de usar los alcances de la API

Puede usar los alcances de la API de distintas maneras:
  • En una API en la que la aplicación que realiza la llamada es una aplicación de terceros o externa. En este caso, la aplicación que realiza la llamada solicitará autorización al usuario para acceder a los alcances solicitados, y el usuario aprobará o denegará la solicitud.
  • En una API en la que la aplicación que realiza la llamada es una aplicación de primera parte, o una aplicación registrada en el mismo dominio de Auth0 que la API a la que llama. En este caso, de forma predeterminada no se solicita el consentimiento del usuario, pero puede configurar que el consentimiento sea obligatorio.
  • En una API en la que la aplicación que realiza la llamada es un servicio de backend, ya sea de terceros o de primera parte, y no existe ningún usuario. En este caso, nunca se solicita el consentimiento del usuario.
Todos estos ejemplos usan alcances para limitar el acceso mediante el uso de un token. Si lo desea, su API también puede usar lógica adicional, además del token, para aplicar un control de acceso más amplio. Para ver un ejemplo de cómo solicitar acceso personalizado a la API para su aplicación, lea Casos de uso de ejemplo: alcances y claims.

​
Ejemplo: una API a la que llama una aplicación de terceros

Supongamos que está creando una API que proporciona información sobre cuentas bancarias a aplicaciones de pago en línea. En distintos momentos, las aplicaciones pueden necesitar consultar los saldos de las cuentas o transferir fondos. Para ello, crea dos alcances para su API: uno que autoriza el acceso de lectura al saldo de una cuenta (read:balance) y otro que autoriza las transferencias de fondos (transfer:funds). Su API está registrada en Auth0. La aplicación que realiza la llamada solicitará autorización al usuario para acceder a los alcances solicitados, y el usuario aprobará o denegará la solicitud. La aplicación puede solicitar acceso de lectura al saldo del usuario incluyendo el alcance read:balance en su solicitud, acceso para realizar transferencias de fondos incluyendo el alcance transfer:funds en su solicitud, o acceso tanto para consultar el saldo del usuario como para transferir fondos incluyendo los alcances read:balance y transfer:funds en su solicitud. Ahora, cuando la aplicación llame a su API, incluirá un token que verifica que el usuario ha autorizado el acceso a su contenido y que también indica qué alcances ha aprobado. Su API debe respetar los alcances aprobados y solo devolver la información que el usuario autorizó para la aplicación que realiza la llamada.

​
Ejemplo: una API invocada por una aplicación propia

Supongamos que estás creando una API que proporciona datos a una aplicación de eventos que también has desarrollado. Implementas el control de acceso basado en roles (RBAC), creando un rol organizer y un rol participant. Los usuarios con el rol organizer necesitan crear y actualizar eventos, mientras que los usuarios con el rol participant necesitan ver eventos y registrarse en ellos. Para ello, creas cuatro alcances para tu API: uno que autoriza la creación de eventos (create:events), otro que autoriza la actualización de eventos (update:events), otro que autoriza el acceso de solo lectura a los eventos (view:events) y otro que autoriza el registro en eventos (register:events). Tanto tu API como la aplicación de eventos están registradas en Auth0, y la opción Allow Skipping User Consent para aplicaciones propias está habilitada para tu API. Has instalado Authorization Extension, configurado un rol organizer, creado para él los alcances create:events y update:events, y lo has asignado al usuario A. También has configurado un rol participant, creado para él los alcances view:events y register:events, y lo has asignado al usuario B. El usuario A se autentica en la aplicación que realiza la llamada, que solicita los alcances necesarios, pero, como se trata de una aplicación propia, no se le pedirá consentimiento al usuario. La aplicación puede solicitar cualquier combinación de los alcances create:events, update:events, view:events y register:events, pero se reconoce que el usuario A tiene el rol organizer y, por lo tanto, solo se le conceden los alcances create:events y update:events. Ahora, cuando la aplicación invoque tu API, incluirá un token que comprueba que solo tiene autorización para los alcances asociados al rol del usuario autenticado.

​
Ejemplo: una API a la que llama un servicio de back-end

Supongamos que trabaja para un hospital y tiene una API que genera grandes volúmenes de datos de imágenes cada vez que a un paciente se le realiza una resonancia magnética. Almacena esos datos de imágenes localmente durante seis meses, pero el hospital necesita conservar las imágenes a largo plazo para cumplir con la normativa. Por ello, el hospital cuenta con un servicio que cada noche copia los datos de imágenes a una solución externa de almacenamiento en frío y elimina todos los datos médicos locales después de seis meses de almacenamiento. Para ello, crea dos alcances para su API: uno que autoriza el acceso de lectura a sus datos de imágenes (read:images) y otro que autoriza el acceso de eliminación a sus datos de imágenes (delete:images). Su API y el servicio automatizado están registrados en Auth0, y usted ha autorizado al servicio automatizado a solicitar tokens para su API. El servicio automatizado que realiza la llamada solicitará los alcances necesarios, pero, como no hay ningún usuario, no se solicitará consentimiento. El servicio puede solicitar acceso de lectura a sus datos de imágenes incluyendo el alcance read:images en su solicitud, acceso de eliminación incluyendo el alcance delete:images en su solicitud, o tanto acceso de lectura como de eliminación incluyendo los alcances read:images y delete:images en su solicitud. Ahora, cuando el servicio automatizado llame a su API, incluirá un token que verifica que tiene autorización para los alcances solicitados.

​
Limitar los alcances de la API

Una aplicación puede incluir en su solicitud cualquier alcance definido para una API. Sin embargo, en lugar de permitir que se soliciten todos los alcances disponibles, puede controlar cómo las aplicaciones acceden a sus API con políticas de acceso a la API para aplicaciones.

​
Más información