> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Comprenda el concepto de los alcances y explore ejemplos generales de su uso.

# Alcances

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.

<div id="ways-to-use-scopes">
  ## Formas de usar los alcances
</div>

Cuando una aplicación solicita permiso para acceder a un recurso a través de un <Tooltip tip="Servidor de autorización: Servidor centralizado que contribuye a definir los límites del acceso de un usuario. Por ejemplo, su servidor de autorización puede controlar los datos, las tareas y las funciones disponibles para un usuario." cta="Ver glosario" href="/es/docs/glossary?term=authorization+server">servidor de autorización</Tooltip>, 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 <Tooltip tip="OpenID: Estándar abierto de autenticación que permite a las aplicaciones verificar las identidades de los usuarios sin recopilar ni almacenar información de inicio de sesión." cta="Ver glosario" href="/es/docs/glossary?term=OpenID">OpenID</Tooltip> Connect (OIDC). Para obtener más información, consulte [Alcances de OpenID Connect](/es/docs/get-started/apis/scopes/openid-connect-scopes).
* En una [API](/es/docs/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](/es/docs/get-started/apis/scopes/api-scopes).
* 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](/es/docs/get-started/apis/scopes/sample-use-cases-scopes-and-claims)

<div id="best-practices">
  ## Prácticas recomendadas
</div>

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.

<div id="requested-scopes-versus-granted-scopes">
  ## Alcances solicitados frente a alcances concedidos
</div>

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 <Tooltip tip="Flujo de autorización: concesión de autorización (o flujo de trabajo) especificado en el marco de OAuth 2.0." cta="Ver glosario" href="/es/docs/glossary?term=authorization+flow">flujo de autorización</Tooltip> 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.

<div id="learn-more">
  ## Más información
</div>

* [Alcances de OpenID Connect](/es/docs/get-started/apis/scopes/openid-connect-scopes)
* [Alcances de API](/es/docs/get-started/apis/scopes/api-scopes)
* [Casos de uso de ejemplo: alcances y claims](/es/docs/get-started/apis/scopes/sample-use-cases-scopes-and-claims)
* [Habilitar el control de acceso basado en roles para las API](/es/docs/get-started/apis/enable-role-based-access-control-for-apis)