> ## 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.
> Escenario de una aplicación web regular que necesita autenticar a los usuarios mediante inicio de sesión único de OpenID Connect (OIDC).
# Aplicaciones web regulares con inicio de sesión único
En este escenario, crearemos una aplicación web para una empresa ficticia llamada ExampleCo. La aplicación está pensada para que la usen los empleados y contratistas de ExampleCo. Los empleados usarán su directorio corporativo existente (Active Directory), mientras que los contratistas se gestionarán en un almacén de usuarios independiente.
### En resumen
* Auth0 admite estándares abiertos como OAuth 2.0 y OpenID Connect (OIDC) para autenticación y autorización (consulte [Qué protocolo usar](/es/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-1#which-protocol-to-use))
* OIDC admite varios flujos de autorización; el más adecuado para aplicaciones web es el Flujo de código de autorización (consulte [Flujo de autenticación](/es/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-1#authentication-flow))
* Su aplicación se configurará en Auth0 como una aplicación (consulte [Aplicación](/es/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-2#application))
* Los Proveedores de identidad se configurarán en Auth0 como una Conexión (consulte [Conexiones](/es/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-2#connections))
* Auth0 proporciona el widget Lock, que permite a los usuarios iniciar sesión en la aplicación (consulte [Inicio de sesión del usuario](/es/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-3#user-login))
* La aplicación web debe gestionar el estado de la sesión para mantener el seguimiento de que el usuario ha iniciado sesión. Además, Auth0 y el Proveedor de identidad también gestionan la información de la sesión. (consulte [Administración de sesiones](/es/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-3#session-management))
* Del mismo modo, cerrar la sesión de un usuario también implica tres capas de administración de sesiones (consulte [Cierre de sesión del usuario](/es/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-3#user-logout))
* El control de acceso se puede gestionar con Authorization Extension de Auth0 (consulte [Control de acceso](/es/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-3#access-control))
Por Aplicación web regular, nos referimos a una aplicación que usa principalmente el lado del servidor, solicitudes de página `GET` y `POST`, y cookies para mantener el estado. Esto contrasta con una Web SPA (aplicación de una sola página), que depende en gran medida de código JavaScript del lado del cliente que llama a una API.
## La premisa
ExampleCo es una startup de consultoría. Actualmente tiene aproximadamente 100 empleados y además subcontrata varias actividades a contratistas externos. La mayoría de los empleados trabajan desde la oficina principal de la empresa, pero algunos equipos trabajan en remoto. Además, algunos empleados viajan con frecuencia a las instalaciones de los clientes y trabajan desde dispositivos móviles.
Todos los empleados y contratistas externos deben completar sus registros de horas cada semana mediante hojas de cálculo. El sistema actual es ineficiente y la empresa decidió que necesita adoptar una solución mejor y más automatizada.
La empresa evaluó varias de las aplicaciones de registro de horas disponibles y concluyó que sería más rentable desarrollar su propia solución interna, ya que por el momento busca una aplicación muy simple. La aplicación se desarrollará con ASP.NET Core, ya que sus desarrolladores ya utilizan esta tecnología y pueden tenerla lista en aproximadamente una semana.
### Objetivos y requisitos
ExampleCo quiere lanzar la nueva solución rápidamente, por lo que eligió empezar de forma sencilla e ir ampliándola a medida que recopila comentarios de sus empleados.
La aplicación debería estar disponible solo para usuarios autenticados. Cada usuario tendrá un rol y, en función de este, debería poder realizar determinadas acciones y ver datos específicos.
### Autenticación vs. autorización
ExampleCo quiere **autenticar** y **autorizar** a cada usuario. La autenticación tiene que ver con la identidad: verificar que el usuario es realmente quien dice ser. La autorización consiste en decidir a qué recursos debería tener acceso un usuario y qué debería poder hacer con esos recursos.
La aplicación de registro de horas de ExampleCo debe admitir dos roles: Usuario y Admin:
* Una persona con el rol de Usuario puede agregar entradas de registro de horas especificando la fecha, la aplicación y las horas trabajadas. El rol de Admin también tiene este mismo derecho.
* Quienes tengan el rol de Usuario deberían tener acceso solo a sus propias entradas de registro de horas.
* Una persona con el rol de Admin puede, además:
* Aprobar o rechazar entradas de registro de horas de otros usuarios.
* Editar la lista desplegable de aplicaciones (agregar, editar, eliminar).
Cada usuario deberá completar sus registros de horas antes de que termine la semana. Puede optar por registrar sus horas a diario o agregar de una sola vez las entradas de toda la semana. Los registros de horas deberán ser revisados y aprobados por un Admin. Las entradas rechazadas deberán ser actualizadas por cada empleado y volver a enviarse para su aprobación.
La empresa usa Active Directory para todos los empleados, y estos iniciarán sesión en la aplicación Timesheet con sus credenciales de Active Directory. Los contratistas externos pueden iniciar sesión con un username y una contraseña. Los contratistas no están en el directorio corporativo de ExampleCo.
ExampleCo quiere minimizar la fricción del inicio de sesión para el usuario, pero quiere mantener un nivel de seguridad acorde con la operación: enviar entradas de registro de horas implica menos riesgo que aprobarlas. Sin embargo, los registros de horas aprobados se usan para la facturación a clientes, por lo que la seguridad es claramente un requisito. La estrategia de autenticación debería ser flexible para poder adaptarse a medida que la empresa crezca. Por ejemplo, deberían poder agregar fácilmente requisitos de autenticación adicionales, como autenticación multifactor, para los Admins.
La solución debería estar disponible tanto para los empleados con presencia física en la oficina de la empresa como para quienes trabajan de forma remota, sin la sobrecarga de una conexión VPN; por lo tanto, la aplicación debería desplegarse en un proveedor de nube como Heroku o Microsoft Azure.
## Más información
* [Descripción general de la solución (Aplicaciones web + SSO)](/es/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-1)
* [Configuración de Auth0 (Aplicaciones web + SSO)](/es/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-2)
* [Implementación de la aplicación (Aplicaciones web + SSO)](/es/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-3)
* [Implementación de ASP.NET Core (Aplicaciones web + SSO)](/es/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/implementation-aspnetcore)
* [Conclusión (Aplicaciones web + SSO)](/es/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-4)