> ## 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. # Usando Access Manager > Usa las APIs de Access Manager para configurar acceso humano, acceso máquina a máquina, MFA y autenticación basada en tokens en tu plataforma Lerian. Access Manager es la forma en que decides quién llega a tus productos Lerian y cómo los sistemas prueban su identidad antes de llamar a una API protegida. Esta guía recorre esa configuración con las APIs. Si prefieres trabajar de forma visual para las tareas comunes de usuarios y aplicaciones, usa [Access Manager vía Lerian Console](/es/platform/access-manager/using-access-manager-with-midaz-console) en su lugar. ## Antes de empezar *** Primero, asegúrate de que el cliente Auth a nivel de ruta de cada producto esté habilitado y configurado con una dirección de Auth. Las rutas protegidas esperan entonces un encabezado `Authorization` con un bearer token válido. ```text theme={null} Authorization: Bearer ``` Cuando el cliente Auth de un producto está habilitado y configurado, las solicitudes sin un bearer token válido se rechazan en sus rutas protegidas, incluso si el endpoint era accesible antes sin autenticación. En despliegues multi-tenant SaaS y BYOC, ese token también lleva el contexto de tu tenant en claims de confianza como `tenantId`, de modo que nunca pasas identificadores de tenant en payloads ni en headers. Más información sobre [multi-tenancy](/es/multi-tenancy). Con las APIs de Identity, el token también es tu límite de tenant: los endpoints de listado devuelven solo los usuarios, grupos y aplicaciones de tu tenant, y las operaciones de creación, actualización y eliminación permanecen dentro de él. ## Acceso humano *** Sigue este flujo cuando una persona necesita acceder a los productos Lerian. Usa [Listar grupos](/es/reference/access-manager/list-groups) para ver los grupos disponibles en tu entorno. Usa [Obtener detalles del grupo](/es/reference/access-manager/retrieve-group-details) cuando necesites inspeccionar los permisos de un grupo específico antes de asignarlo. En despliegues multi-tenant, la lista se delimita al tenant que lleva el bearer token. Usa los IDs de grupo devueltos tal cual al crear o actualizar usuarios. Comprueba los recursos y acciones de cada grupo antes de asignarlo. Los permisos de Access Manager se evalúan como pares exactos de recurso-acción, como `reports:get`, `users:patch` o `transfers:read`. Algunos productos usan acciones al estilo de los métodos HTTP, mientras que otros usan acciones semánticas como `read`, `write`, `create` o `process`. Usa los permisos que devuelve la API en lugar de derivar nombres de permisos a partir de las rutas de los endpoints. Usa [Crear un usuario](/es/reference/access-manager/create-user) y asigna los grupos correctos durante la creación. La asignación de grupos define a qué puede acceder el usuario. Por ejemplo, asignar un grupo de solo lectura de Midaz permite al usuario inspeccionar recursos de Midaz sin modificarlos. Usa [Solicitar un token de acceso](/es/reference/access-manager/request-access-token) con el tipo de concesión `password`. El access token devuelto se usa como bearer token cuando el usuario llama a las APIs protegidas. Usa [Renovar el token de acceso](/es/reference/access-manager/refresh-token) para intercambiar un refresh token válido por un nuevo access token. ### Endpoints de gestión de usuarios Usa estos endpoints para mantener el acceso humano a lo largo del tiempo: * [Listar usuarios](/es/reference/access-manager/list-users) — lista usuarios. * [Obtener detalles del usuario](/es/reference/access-manager/retrieve-user-details) — inspecciona un usuario. * [Actualizar un usuario](/es/reference/access-manager/update-user) — actualiza la información y las asignaciones de grupos de un usuario. * [Eliminar un usuario](/es/reference/access-manager/delete-user) — elimina el acceso de un usuario. * [Restablecer la contraseña de un usuario](/es/reference/access-manager/reset-user-password) — restablece la contraseña de un usuario mediante un flujo administrativo. * [Actualizar la contraseña de un usuario](/es/reference/access-manager/update-user-password) — actualiza la contraseña de un usuario con la contraseña actual y la nueva. ## Acceso máquina a máquina *** Cuando un servicio, job o integración necesita llamar a las APIs de Lerian sin una persona de por medio, dale su propia aplicación. Usa [Crear una aplicación](/es/reference/access-manager/create-an-application) para crear credenciales para la integración. Cada integración debe tener su propia aplicación. Esto facilita la rotación de credenciales y las revisiones de acceso. La respuesta incluye el `clientId` y el `clientSecret` que usa Auth en el flujo `client_credentials`. Usa [Listar aplicaciones](/es/reference/access-manager/list-applications), [Obtener una aplicación](/es/reference/access-manager/retrieve-application-details) o [Eliminar una aplicación](/es/reference/access-manager/delete-application) cuando necesites revisar o eliminar el acceso máquina a máquina. Identity oculta las aplicaciones internas de la lista. En despliegues multi-tenant, solo devuelve las aplicaciones vinculadas a la organización del tenant de quien hace la llamada. Usa [Solicitar un token de acceso](/es/reference/access-manager/request-access-token) con el tipo de concesión `client_credentials`. El access token devuelto se usa como bearer token para las llamadas a la API de la integración. ### Catálogo actual de aplicaciones M2M El catálogo actual de aplicaciones acepta estos nombres al crear aplicaciones machine-to-machine: | Nombre de la aplicación | Producto | | ---------------------------- | ----------------- | | `midaz` | Midaz Ledger | | `plugin-fees` | Fees Engine | | `plugin-crm` | CRM | | `reporter` | Reporter | | `fetcher` | Fetcher | | `plugin-br-pix-jd` | Pix Direct JD | | `plugin-br-pix-indirect-btg` | Pix Indirect BTG | | `plugin-br-bank-transfer` | Bank Transfer | | `plugin-br-pix-switch-spi` | Pix Switch (SPI) | | `plugin-br-pix-switch-dict` | Pix Switch (DICT) | | `plugin-br-pix-switch-cob` | Pix Switch (COB) | | `flowker` | Flowker | | `streaming-hub` | Streaming Hub | | `br-sta` | STA | | `br-sisbajud` | Sisbajud | Identity acepta solo los nombres de este catálogo al crear o eliminar aplicaciones máquina a máquina. ## Configuración de proveedores *** Usa proveedores cuando una aplicación necesita un proveedor de comunicación configurado para entrega de MFA, como email o SMS. El SSO en navegador usa una configuración independiente de proveedor OAuth y política SSO; consulta el [servicio Identity](/es/platform/access-manager/identity-plugin). 1. Crea o revisa un proveedor con la [API de proveedores](/es/reference/access-manager/list-providers). 2. Vincula el proveedor a la aplicación con [Vincular un proveedor a una aplicación](/es/reference/access-manager/link-provider-to-application). 3. Si la aplicación tiene varios proveedores vinculados, usa [Establecer el proveedor predeterminado de una aplicación](/es/reference/access-manager/set-default-application-provider) para seleccionar el proveedor predeterminado. Usa los endpoints de proveedor-aplicación cuando necesites listar, actualizar, desvincular o reordenar los vínculos de proveedores de una aplicación. ## Configuración de MFA *** Usa MFA para los usuarios que necesitan un paso adicional de verificación al iniciar sesión. Usa [Iniciar la configuración de MFA](/es/reference/access-manager/initiate-mfa-setup) en la propia cuenta del usuario autenticado y para el método MFA seleccionado. Usa [Verificar el código de MFA](/es/reference/access-manager/verify-mfa-passcode) para confirmar el método. Usa [Habilitar MFA](/es/reference/access-manager/enable-mfa) después de verificar la configuración. Usa [Obtener el estado de MFA](/es/reference/access-manager/get-mfa-status), [Establecer el método de MFA preferido](/es/reference/access-manager/set-preferred-mfa-method) o [Deshabilitar MFA](/es/reference/access-manager/disable-mfa) a medida que cambian los requisitos de acceso del usuario. Durante el inicio de sesión, los usuarios con MFA habilitado pueden necesitar completar [Iniciar el desafío de MFA](/es/reference/access-manager/initiate-mfa-challenge) con el token MFA y el método seleccionado, y después [Verificar el desafío de MFA](/es/reference/access-manager/verify-mfa-login), antes de recibir access tokens utilizables. Los cambios administrativos de MFA usan operaciones administrativas independientes. ## Información de usuario y control de sesión *** Una vez que un usuario está activo, algunos endpoints ayudan a inspeccionar y controlar esa sesión. [Obtener información del usuario](/es/reference/access-manager/retrieve-user-information) devuelve su perfil compatible con OIDC, y [Obtener permisos del usuario](/es/reference/access-manager/retrieve-user-permissions) muestra los recursos y acciones a los que puede acceder. Para finalizar una sesión, llama a [Finalizar sesión del usuario](/es/reference/access-manager/end-user-session) con el campo de formulario obligatorio `id_token_hint` de esa sesión; este endpoint no selecciona a otro usuario por ID. ## Comprobaciones de permisos *** Los productos protegidos llaman a Auth con el recurso y la acción que necesitan aplicar. Usa [Validar permisos del usuario](/es/reference/access-manager/validate-user-permission) cuando una integración necesita comprobar una decisión de acceso de forma explícita. ```json theme={null} { "resource": "reports", "action": "get" } ``` La respuesta te indica si el sujeto autenticado está autorizado para ese par recurso-acción. ## Reglas de acceso multi-tenant *** El flujo público de la API usa los mismos endpoints en despliegues single-tenant y multi-tenant, pero el comportamiento multi-tenant añade resolución y validación de credenciales específicas del tenant: * En despliegues multi-tenant, Auth e Identity resuelven el tenant a partir del contexto de confianza del token o de la aplicación. Para las concesiones de contraseña, Auth usa credenciales de aplicación del tenant cuando están disponibles y mantiene la caché de tokens consciente del tenant. Identity también permite crear usuarios nuevos solo cuando puede confirmar que el dominio de email coincide con el administrador de referencia del tenant. * En despliegues single-tenant, Access Manager usa la organización predeterminada configurada. Por eso no añadas IDs de tenant a los payloads de Identity o Auth a menos que un endpoint documente explícitamente ese campo. Después de la autenticación, las claims del bearer token acotan las llamadas normales de gestión y permisos de Identity. Las concesiones de contraseña y client credentials resuelven el contexto de tenant antes de que exista un bearer token.