Saltar al contenido principal
La información de los usuarios suele estar distribuida entre varios recursos en línea. Los usuarios pueden subir y almacenar fotos en un servicio como Flickr, guardar archivos digitales en Dropbox y almacenar contactos y eventos en Google Calendar o Facebook. Con frecuencia, las aplicaciones nuevas quieren utilizar información que ya se ha creado en un recurso en línea. Para ello, la aplicación debe solicitar autorización para acceder a esa información en nombre del usuario. Los alcances definen las acciones específicas que se puede permitir que una aplicación realice en nombre del usuario.

​
Formas de usar los alcances

Cuando una aplicación solicita permiso para acceder a un recurso a través de un , utiliza el parámetro scope para especificar qué acceso necesita, y el servidor de autorización usa el parámetro scope para devolver el acceso que realmente se concedió (si el acceso concedido fue distinto del solicitado). En general, los alcances se usan de tres maneras:
  • Desde una aplicación, para verificar la identidad de un usuario y obtener información básica de su perfil, como su correo electrónico o su foto. En este escenario, los alcances disponibles incluyen los implementados por el protocolo Connect (OIDC). Para obtener más información, consulte Alcances de OpenID Connect.
  • En una API, para implementar el control de acceso. En este caso, debe definir alcances personalizados para su API y luego dar a conocer esos alcances para que las aplicaciones que la llamen puedan utilizarlos. Para obtener más información, consulte Alcances de API.
  • Desde una aplicación, para llamar a una API que ha implementado sus propios alcances personalizados. En este caso, debe saber qué alcances personalizados están definidos para la API a la que llama. Para ver ejemplos de llamadas a una API personalizada desde una aplicación, consulte Casos de uso de ejemplo: alcances y claim

​
Prácticas recomendadas

Comprenda su caso de uso y elija los alcances más restrictivos posibles. Si solicita alcances, asegúrese de pedir el acceso suficiente para que su aplicación funcione, pero solicite solo lo que realmente necesita. ¿Está estableciendo la identidad de un usuario o pidiéndole que le permita interactuar con sus datos? Hay una gran diferencia entre importar la información del perfil de Facebook de un usuario y publicar en su muro. Si solicita solo lo que necesita, tendrá más probabilidades de obtener el consentimiento del usuario cuando sea necesario, ya que los usuarios suelen ser más propensos a conceder acceso para alcances limitados y claramente especificados. Del mismo modo, al crear alcances personalizados para una API, considere qué niveles de acceso granular pueden necesitar las aplicaciones y diseñe en consecuencia.

​
Alcances solicitados frente a alcances concedidos

En ciertos casos, los usuarios pueden dar su consentimiento para el acceso solicitado. Aunque, por lo general, los alcances devueltos serán idénticos a los solicitados, los usuarios pueden modificar los alcances concedidos (tanto durante el consentimiento inicial como, a veces, después, según el recurso), lo que permite otorgar a una aplicación menos acceso del que solicitó. Como desarrollador de aplicaciones, debe tener en cuenta esta posibilidad y manejar estos casos en su aplicación. Por ejemplo, su aplicación podría advertir al usuario de que tendrá una funcionalidad reducida. También podría hacer que el usuario vuelva a pasar por el para solicitar permisos adicionales. Pero, una vez más, recuerde que, cuando se les pide su consentimiento, los usuarios siempre pueden negarse. De forma predeterminada, Auth0 omite el consentimiento del usuario para las aplicaciones de primera parte, es decir, las aplicaciones registradas en el mismo dominio de Auth0 que la API a la que llaman; sin embargo, puede configurar su API en Auth0 para exigir el consentimiento del usuario en las aplicaciones de primera parte. Las aplicaciones de terceros, es decir, aplicaciones externas, requieren el consentimiento del usuario.

​
Más información