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

> Explica el escenario de arquitectura en el que una aplicación de página única (SPA) se comunica con una API mediante OpenID Connect (OIDC) y el flujo de concesión implícita de OAuth 2.0 para autenticar usuarios con Auth0.

# Aplicaciones de página única (SPA) con API

En este escenario, crearemos una API de registro de horas para una empresa ficticia llamada ExampleCo. La API permitirá agregar registros de horas para un empleado o un contratista.

También crearemos una aplicación de página única (SPA) que se utilizará para registrar horas y enviarlas a la base de datos centralizada de registro de horas mediante la API.

<Info>
  ### En resumen

  * Auth0 proporciona autenticación y autorización para API como medio para proteger el acceso a los endpoint de la API (consulte [API Authentication and Authorization](/es/docs/get-started/architecture-scenarios/spa-api/part-1#api-authentication-and-authorization))
  * Para autorizar a un usuario de una SPA, Auth0 admite el flujo de concesión implícita (consulte [Implicit Grant](/es/docs/get-started/architecture-scenarios/spa-api/part-1#implicit-grant))
  * Tanto la SPA como la API deben configurarse en el Auth0 Dashboard (consulte [Auth0 Configuration](/es/docs/get-started/architecture-scenarios/spa-api/part-2#auth0-configuration))
  * Los permisos de usuario se pueden aplicar mediante la Authorization Extension (consulte [Configure the Authorization Extension](/es/docs/get-started/architecture-scenarios/spa-api/part-2#configure-the-authorization-extension))
  * La API estará protegida al garantizar que se envíe un Token de acceso válido en el encabezado HTTP Authorization cuando se realicen llamadas a la API (consulte [Implement the API](/es/docs/get-started/architecture-scenarios/spa-api/part-3#implement-the-api))
  * La biblioteca Auth0.js se puede usar para autorizar al usuario de la SPA y obtener un Token de acceso válido que puede usarse para llamar a la API (consulte [Authorize the User](/es/docs/get-started/architecture-scenarios/spa-api/part-3#authorize-the-user))
  * La SPA puede incluir el Token de acceso en el encabezado HTTP Authorization al realizar llamadas a la API (consulte [Call the API](/es/docs/get-started/architecture-scenarios/spa-api/part-3#call-the-api))
  * La SPA puede mostrar elementos de la interfaz de usuario de forma condicional según los alcances concedidos al usuario (consulte [Display UI Elements Conditionally Based on Scope](/es/docs/get-started/architecture-scenarios/spa-api/part-3#display-ui-elements-conditionally-based-on-scope))
</Info>

<div id="the-premise">
  ## El planteamiento
</div>

ExampleCo es una startup de consultoría. Actualmente, tiene aproximadamente 100 empleados y además externaliza varias actividades a contratistas externos. Todos los empleados y los contratistas externos deben completar su registro de horas cada semana.

La empresa ha desarrollado una aplicación de registro de horas, un escenario que tratamos en [Inicio de sesión único para aplicaciones web tradicionales](/es/docs/get-started/architecture-scenarios/sso-for-regular-web-apps). Los empleados internos usan esta aplicación web para completar su registro de horas, pero la empresa quiere reemplazarla por una SPA. La aplicación se utilizará para registrar entradas de horas y enviar los datos a la base de datos centralizada de registro de horas mediante la API. La aplicación también permitirá a los gerentes aprobar las entradas de horas.

<div id="goals-requirements">
  ## Objetivos y requisitos
</div>

ExampleCo quiere desarrollar una solución flexible. Por el momento, solo se necesita una SPA para registrar entradas de registro de horas, pero en el futuro la empresa planea lanzar más aplicaciones, como una aplicación móvil para sus equipos de ventas. Por ello, la empresa ha decidido desarrollar una única API de registros de horas que se utilizará para registrar tiempo no solo mediante este proceso del servidor, sino también mediante todas las aplicaciones futuras. Quieren implementar una arquitectura de seguridad lo suficientemente flexible para dar cabida a esto. ExampleCo quiere garantizar que gran parte del código y de la lógica de negocio de la aplicación pueda compartirse entre las distintas aplicaciones.

Se requiere que solo los usuarios y las aplicaciones autorizados tengan acceso a la API de registros de horas.

Esta SPA será utilizada por dos tipos de usuarios: empleados y gerentes. Los empleados deben poder leer, crear y eliminar sus propias entradas de registro de horas, mientras que los gerentes también deben poder aprobar registros de horas.

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

* [Descripción general de la solución (SPAs + API)](/es/docs/get-started/architecture-scenarios/spa-api/part-1)
* [Configuración de Auth0 (SPAs + API)](/es/docs/get-started/architecture-scenarios/spa-api/part-2)
* [Configuración de la API y la SPA (SPAs + API)](/es/docs/get-started/architecture-scenarios/spa-api/part-3)
* [Implementación de la API de Node.js (SPAs + API)](/es/docs/get-started/architecture-scenarios/spa-api/api-implementation-nodejs)
* [Implementación de la SPA Angular 2 (SPAs + API)](/es/docs/get-started/architecture-scenarios/spa-api/spa-implementation-angular2)
* [Conclusión (SPAs + API)](/es/docs/get-started/architecture-scenarios/spa-api/part-4)