> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.
# Servicio Auth
> El servicio Auth emite tokens OAuth2/OIDC, valida sesiones, verifica permisos y gestiona desafíos de MFA durante el inicio de sesión de usuarios.
Auth es el servicio de acceso en tiempo de ejecución de Access Manager. Se sitúa entre tus productos Lerian protegidos y el proveedor de identidad configurado, y ofrece a los productos una única interfaz para el ciclo de vida del token, la información de usuario, las comprobaciones de permisos, el cierre de sesión y la verificación de inicio de sesión con MFA.
Usa Auth cuando necesites:
* solicitar tokens de acceso para usuarios humanos o aplicaciones máquina a máquina;
* refrescar un token de acceso expirado;
* recuperar información de usuario compatible con OIDC;
* validar si un sujeto puede realizar una acción sobre un recurso;
* recuperar los permisos disponibles para el usuario autenticado;
* finalizar una sesión de usuario;
* iniciar y verificar desafíos de MFA durante el inicio de sesión.
Auth delega los datos de identidad en el proveedor de identidad y cachea con Valkey los datos de token, permisos y MFA para reducir las llamadas repetidas durante la operación normal.
## Flujos principales
***
Auth admite los flujos de acceso que usan los productos e integraciones de Lerian.
### Flujo de autenticación
1. **Solicitud de token**
* Los usuarios humanos se autentican con el grant `password`.
* Las integraciones de servicio se autentican con el grant `client_credentials`.
* Auth reenvía la solicitud al proveedor de identidad y devuelve el token de acceso, el token de refresco y el token ID cuando corresponde.
2. **Refresco de token**
* Los clientes intercambian un token de refresco por un nuevo token de acceso.
* Auth valida el token de refresco con el proveedor de identidad antes de emitir el nuevo token.
3. **Validación de token**
* Los productos protegidos validan los bearer tokens antes de aceptar una solicitud.
* Auth extrae las claims de token de confianza para identificar el sujeto y el contexto de tenant.
* Los resultados de validación pueden cachearse para reducir las llamadas repetidas al proveedor de identidad.
### Contexto de organización
Para la autorización, Auth usa el claim JWT `owner` cuando está presente y, si no, la organización configurada. El producto que recibe una solicitud autorizada controla su propio contexto de datos de tenant y el aislamiento del plano de datos. No infieras un flujo de resolución de tenant entre productos solo a partir de Auth.
Para la configuración de despliegues multi-tenant, sigue la documentación del producto correspondiente y de [multi-tenancy](/es/multi-tenancy).
### Flujo SSO en navegador
1. **Inicia el flujo**
* El navegador inicia SSO a través de Auth con una dirección de email, un proveedor elegible y un `code_challenge` PKCE S256. Auth resuelve el tenant en el servidor a partir del dominio de email y redirige el navegador al proveedor de identidad upstream.
2. **Gestiona el callback**
* El proveedor de identidad redirige el navegador a `PLUGIN_AUTH_SSO_CALLBACK_URL`. Esta URL de callback absoluta debe estar registrada en la lista de URI de redirección permitidas de la aplicación del proveedor de identidad.
* La Console envía el código de autorización del proveedor, el estado de Auth y el `codeVerifier` PKCE correspondiente mediante el grant `sso_code` de Auth. Auth consume el flujo una vez, retransmite el código al proveedor de identidad y devuelve el conjunto de tokens.
Configura el proveedor OAuth y la política SSO del tenant mediante [Identity](/es/platform/access-manager/identity-plugin). La URL de callback de Auth debe coincidir con la URI de redirección permitida de la aplicación.
### Flujo de inicio de sesión con MFA
1. **Desafío requerido**
* Cuando se requiere MFA, Auth devuelve un estado de desafío de MFA en lugar de completar el inicio de sesión de inmediato.
2. **Inicia la entrega del desafío**
* Para MFA por email o SMS, el cliente envía el token MFA devuelto y el método seleccionado para solicitar la entrega del desafío, y Auth envía el código de desafío mediante ese método.
* Una aplicación TOTP genera su código de acceso localmente, sin una solicitud de entrega.
3. **Verificación del desafío**
* El usuario envía el token de MFA y un código de acceso o un código de recuperación, no ambos.
* Auth verifica el desafío y devuelve los tokens de acceso cuando la verificación es correcta.
4. **Controles de sesión**
* Los desafíos de MFA expiran tras el TTL configurado.
* Los intentos fallidos están limitados para proteger la cuenta de adivinación repetida.
### Flujo de autorización
1. **Aplicar acceso**
* Un producto protegido pregunta si el sujeto autenticado puede realizar una acción específica sobre un recurso específico.
* Auth evalúa la solicitud contra los permisos de Access Manager configurados.
* Las decisiones de autorización correctas pueden cachearse para mejorar el rendimiento.
2. **Recuperar permisos**
* Un cliente puede recuperar los permisos disponibles para el usuario autenticado.
* Auth devuelve los permisos como un mapa de recursos a acciones permitidas.
### Flujo de información del usuario
1. **Solicitud de perfil**
* El cliente solicita información del perfil de usuario con un bearer token.
* Auth valida el token y recupera los detalles del usuario del proveedor de identidad.
* Auth devuelve la información de usuario compatible con OIDC.
### Flujo de cierre de sesión
1. **Cierre de sesión del usuario**
* El cliente envía una solicitud de cierre de sesión con la pista de token ID (ID token hint).
* Auth invalida la sesión en el proveedor de identidad.
* Las entradas de caché relacionadas se eliminan.
## Descripción general de la API
***
Auth expone APIs para:
* solicitar tokens de acceso con `password` o `client_credentials`;
* refrescar tokens de acceso;
* finalizar sesiones de usuario;
* validar permisos de usuario;
* recuperar información de usuario;
* recuperar permisos de usuario;
* iniciar, completar y descubrir flujos SSO en navegador;
* iniciar un desafío de MFA;
* verificar un desafío de inicio de sesión con MFA.
Auth expone puntos de entrada con credenciales y operaciones protegidas. Sigue los requisitos de seguridad documentados para cada endpoint. Para obtener detalles técnicos sobre endpoints y uso, consulta la documentación de [APIs de Auth](/es/reference/access-manager/am-auth-apis).
## Decisiones de permisos
***
Cuando un producto protegido pregunta a Auth si un sujeto puede realizar una acción sobre un recurso, Auth resuelve el sujeto (un usuario humano o una aplicación máquina a máquina), busca los permisos asociados a él y devuelve una decisión de autorizado o denegado.
Para los usuarios humanos, Auth evalúa los permisos integrados en sus datos de identidad, incluidos los permisos directos de usuario y los roles aplicables. Para las aplicaciones máquina a máquina, los permisos provienen del conjunto de permisos configurado de la aplicación. Auth no inventa permisos; evalúa los datos que gestiona Identity.
Para el modelo completo de sujeto/recurso/acción, ejemplos y cómo se protegen las rutas, consulta [Aplicación a nivel de producto](/es/platform/access-manager/product-level-enforcement). Para inspeccionar a qué puede llegar el sujeto autenticado, usa [Obtener permisos del usuario](/es/reference/access-manager/retrieve-user-permissions).
## Almacenamiento de datos y caching
***
Auth usa datos de política estructurados y entradas de caché para reducir el trabajo repetido:
* **Datos de política**: almacena las reglas de control de acceso para usuarios, grupos y aplicaciones.
* **Caché de token**: almacena los resultados de validación de token.
* **Caché de permisos**: almacena las decisiones de autorización correctas.
* **Caché de permisos de usuario**: almacena el mapa de recursos y acciones disponibles para un usuario.
* **Caché de MFA**: almacena el estado temporal del desafío, los contadores de intentos y el estado de recordar dispositivo cuando está configurado.
## Pruebas y fiabilidad
***
**Auth** se somete a pruebas continuas para mantener la fiabilidad y la seguridad. Las pruebas cubren:
* **Flujos de autenticación y validación de tokens**.
* **Aplicación del control de acceso**.
* **Rendimiento y eficiencia del caching**.
Auth también ejecuta evaluaciones de seguridad y monitorización continuas en todos estos flujos.