> ## 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 la solución para el escenario de arquitectura de SPA + API

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

Para garantizar que solo los usuarios y las aplicaciones autorizados puedan acceder a la API de Timesheets, ExampleCo ha decidido utilizar el [marco de autorización de OAuth 2.0](https://tools.ietf.org/html/rfc6749). Este marco 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 Timesheets.

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

Una API es una forma de exponer la funcionalidad de su aplicación a otras aplicaciones. Una aplicación puede hacer una solicitud enviando un mensaje a un endpoint de una API y recibir información como respuesta.

Un endpoint de API puede estar protegido o no. En nuestro caso, dado que los registros de horas son información confidencial que afecta a las revisiones y los pagos, es importante garantizar que solo los usuarios y las aplicaciones autorizados puedan llamar a los endpoints de nuestra API. Cuando una aplicación cliente quiere acceder a endpoints protegidos de una API, necesita presentar un <Tooltip tip="Token de acceso: Credencial de autorización, en forma de una cadena opaca o JWT, utilizada para acceder a una API." cta="Ver glosario" href="/es/docs/glossary?term=Access+Token">Token de acceso</Tooltip> como prueba de que tiene los permisos necesarios para llamar al endpoint.

Un Token de acceso se obtiene autenticando al usuario con 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>, y el usuario puede luego autorizar a la aplicación para acceder a la API en su nombre.

<Card title="¿Qué es un Token de acceso?">
  Un Token de acceso (también denominado `access_token`) es una cadena opaca que representa una autorización emitida para la aplicación. Puede indicar un identificador utilizado para recuperar la información de autorización o puede contener en sí mismo la información de autorización (por ejemplo, la identidad del usuario, los permisos, etc.) de forma verificable.

  Es bastante común que los Tokens de acceso se implementen como [JSON Web Tokens](/es/docs/secure/tokens/json-web-tokens).

  Para obtener más información sobre los Tokens de acceso de Auth0, consulte [Token de acceso](/es/docs/secure/tokens/access-tokens).
</Card>

Una API puede aplicar un control detallado sobre quién puede acceder a los distintos endpoints expuestos por la API. Estos permisos se expresan como alcances.

Cuando un usuario autoriza una aplicación cliente, la aplicación también puede indicar qué permisos requiere. A continuación, el usuario puede revisar y conceder estos permisos. Estos permisos se incluyen entonces en el Token de acceso como parte del claim `scope`.

Posteriormente, cuando el cliente envía el Token de acceso al realizar solicitudes a la API, la API puede inspeccionar el claim `scope` para asegurarse de que se hayan concedido los permisos necesarios para llamar a ese endpoint de API en particular.

<Card title="¿Qué son los Scopes?">
  Cada Token de acceso puede incluir una lista de los permisos que se han concedido al cliente. Cuando un cliente se autentica con Auth0, especificará la lista de alcances (o permisos) que solicita. Si esos alcances están autorizados, entonces el Token de acceso contendrá una lista de alcances autorizados.

  Por ejemplo, la API de registro 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`).

  Cuando un cliente solicita a la API crear una nueva entrada de registro de horas, el Token de acceso debe contener el scope `create:timesheets`. 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 sobre los alcances, consulte [Scopes](/es/docs/get-started/apis/scopes).
</Card>

Al usar el marco de autorización <Tooltip tip="OAuth 2.0: Framework de autorización que define protocolos y flujos de autorización." cta="Ver glosario" href="/es/docs/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip>, puede dar a sus propias aplicaciones o a aplicaciones de terceros acceso limitado a sus API en nombre de la propia aplicación. Con Auth0, puede admitir fácilmente distintos flujos en sus propias API sin preocuparse por la especificación OAuth 2.0/<Tooltip tip="OpenID: Estándar abierto para 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) ni por los muchos otros 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:

  * **Propietario del recurso**: la entidad que puede otorgar acceso a un recurso protegido. Normalmente, es el usuario final.
  * **Servidor de recursos**: el servidor que aloja los recursos protegidos. Es la API a la que quieres acceder.
  * **Cliente**: una aplicación que solicita acceso a un recurso protegido en nombre del propietario del recurso.
  * **Servidor de autorización**: el servidor que autentica al propietario del recurso 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 conceder a las aplicaciones acceso limitado a las API que estás creando. Como resultado, la aplicación obtendrá un token de acceso que podrá usar para invocar la API en nombre del usuario.
</Card>

<div id="implicit-grant">
  ## Concesión implícita
</div>

OAuth 2.0 proporciona varios **tipos de concesión** para distintos casos de uso. En este caso concreto, queremos acceder a la API desde una [aplicación del lado del cliente](/es/docs/quickstart/spa).

La SPA usará el [Flujo implícito (Concesión implícita)](/es/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post) para hacerlo.

La Concesión implícita (definida en [RFC 6749, sección 4.1](https://tools.ietf.org/html/rfc6749#section-4.2)) es similar a la concesión utilizada en el [Flujo de código de autorización](/es/docs/get-started/authentication-and-authorization-flow/authorization-code-flow), pero la principal diferencia es que la aplicación recibe un Token de acceso directamente, sin necesidad de un `authorization_code`. Esto ocurre porque la aplicación, que normalmente es una aplicación JavaScript que se ejecuta en un navegador, es menos fiable que una aplicación web que se ejecuta en el servidor y, por lo tanto, no puede considerarse de confianza para manejar el `client_secret` (que es obligatorio en la Concesión de código de autorización).

Una vez que el usuario se autentica, la aplicación recibe el <Tooltip tip="ID Token: Credencial destinada al propio cliente, no al acceso a un recurso." cta="Ver glosario" href="/es/docs/glossary?term=ID+Token">ID Token</Tooltip> y el Token de acceso en el fragmento hash de la URI. La aplicación ya puede usar el ID Token para obtener información sobre el usuario y el Token de acceso para llamar a la API en nombre del usuario.

1. La aplicación inicia el flujo y redirige el navegador a Auth0 (concretamente al [endpoint /authorize](https://auth0.com/docs/api/authentication#implicit-grant)), para que el usuario pueda autenticarse.
2. Auth0 autentica al usuario. La primera vez que el usuario complete este flujo, y si la aplicación es de terceros, se mostrará una página de consentimiento en la que se enumeran los permisos que se otorgarán al cliente (por ejemplo, publicar mensajes, listar contactos, etc.).
3. Auth0 redirige al usuario a la aplicación con un Token de acceso (y, opcionalmente, un ID Token) en el fragmento hash de la URI. La aplicación ya puede extraer los tokens del fragmento hash.
4. La aplicación puede usar el Token de acceso para llamar a la API en nombre del usuario.

<div id="authorization-extension">
  ## Authorization Extension
</div>

La [Auth0 Authorization Extension](/es/docs/customize/extensions/authorization-extension) permite configurar Roles, Groups y Permissions, y asignarlos a los usuarios.

* Los Permissions son acciones que alguien puede realizar. Para las necesidades de negocio de ExampleCo, configuraremos cuatro Permissions: leer, crear, eliminar y aprobar registros de horas.
* Los Roles son conjuntos de Permissions. La aplicación de registros de horas de ExampleCo será utilizada por dos tipos de usuarios (empleados y gerentes), cada uno con permisos diferentes, por lo que configuraremos dos Roles: empleado y gerente.

Como esto cubre nuestro caso de uso, no crearemos ningún Groups.

Authorization Extension creará una [Rule](/es/docs/customize/rules) que leerá los Roles, Groups y Permissions asignados a un usuario y añadirá esta información al [perfil de usuario](/es/docs/customize/rules#rule-syntax) durante el flujo de autenticación. Podemos usar esta información para garantizar que el Token de acceso emitido a un usuario solo contenga los alcances permitidos. Más adelante, podremos personalizar nuestra aplicación; por ejemplo, deshabilitar la funcionalidad para aprobar registros de horas si el usuario no tiene el permiso requerido para hacerlo.