> ## 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.

> Descripción general de las soluciones para el escenario de arquitectura Servidor + API

# Descripción general de la solución (Aplicaciones de servidor + API)

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](https://tools.ietf.org/html/rfc6749). 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.

<div id="oauth-20">
  ## OAuth 2.0
</div>

Al usar el marco de autorización <Tooltip tip="OAuth 2.0: marco de autorización que define protocolos y flujos de trabajo de autorización." cta="Ver glosario" href="/es/docs/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip>, 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](/es/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use) o flujos de autenticación sin tener que preocuparse por la especificación OAuth 2.0/<Tooltip tip="OpenID: estándar abierto de autenticación que permite a las aplicaciones verificar la identidad 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) ni por muchos de los demás aspectos técnicos de la autorización de API.

<Card title="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)](/es/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use) 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.
</Card>

<div id="client-credentials-grant">
  ### Concesión de credenciales de cliente
</div>

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 <Tooltip tip="Propietario del recurso: Entidad (como un usuario o una aplicación) capaz de conceder acceso a un recurso protegido." cta="Ver glosario" href="/es/docs/glossary?term=resource+owner">propietario del recurso</Tooltip>) 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 <Tooltip tip="Servidor de recursos: Servidor que aloja recursos protegidos. Los servidores de recursos aceptan y responden a solicitudes de recursos protegidos." cta="Ver glosario" href="/es/docs/glossary?term=Resource+Server">Servidor de recursos</Tooltip> (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/docs/get-started/authentication-and-authorization-flow/client-credentials-flow) es ideal. Con la Concesión de credenciales de cliente (definida en [RFC 6749, sección 4.4](https://tools.ietf.org/html/rfc6749#section-4.4)), una aplicación puede solicitar directamente un <Tooltip tip="Token de acceso: Credencial de autorización, en forma de una cadena opaca o un JWT, utilizada para acceder a una API." cta="Ver glosario" href="/es/docs/glossary?term=access+token">token de acceso</Tooltip> al <Tooltip tip="Token de acceso: Credencial de autorización, en forma de una cadena opaca o un JWT, utilizada para acceder a una API." cta="Ver glosario" href="/es/docs/glossary?term=Authorization+Server">Servidor de autorización</Tooltip> mediante sus credenciales de cliente (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=Client+ID">ID de cliente</Tooltip> y un <Tooltip tip="Secreto del cliente: Secreto que utiliza un cliente (aplicación) para autenticarse ante el Servidor de autorización; solo debe conocerlo el cliente y el Servidor de autorización, y debe ser lo suficientemente aleatorio como para que no pueda adivinarse." cta="Ver glosario" href="/es/docs/glossary?term=Client+Secret">Secreto del cliente</Tooltip>). En lugar de identificar a un propietario del recurso, este token representará a la propia aplicación.

<Frame>
  <img src="https://mintcdn.com/translations/MV7tE-x71x8RWRES/docs/images/cdy7uua7fh8z/5CfNEkbyG1ZC5BqHwi9gEs/309babf8329b165f1241f4cbc8e002ba/client-credentials-grant.png?fit=max&auto=format&n=MV7tE-x71x8RWRES&q=85&s=94755d8d68bfaf27437b43220939ef8c" alt="undefined" width="750" height="286" data-path="docs/images/cdy7uua7fh8z/5CfNEkbyG1ZC5BqHwi9gEs/309babf8329b165f1241f4cbc8e002ba/client-credentials-grant.png" />
</Frame>

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.

<div id="api-authentication-and-authorization">
  ## Autenticación y autorización de API
</div>

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.

<div id="access-tokens-and-scopes">
  ### Tokens de acceso y alcances
</div>

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](/es/docs/secure/tokens/access-tokens).

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](/es/docs/get-started/apis/scopes).

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](/es/docs/get-started/apis/scopes).