> ## 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. 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 Access Manager esté habilitado para los productos que quieres proteger. A partir de ese punto, cada API protegida espera un encabezado `Authorization` con un bearer token válido. ```text theme={null} Authorization: Bearer ``` Las solicitudes sin un bearer token válido se rechazan una vez que Access Manager está habilitado, 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 La semilla y las migraciones actuales de Access Manager definen permisos M2M para estos nombres de aplicación: | Nombre de la aplicación | Producto | | ---------------------------- | ---------------- | | `midaz` | Midaz Ledger | | `plugin-fees` | Fees Engine | | `plugin-crm` | CRM | | `reporter` | Reporter | | `plugin-br-pix-direct-jd` | Pix Directo JD | | `plugin-br-pix-indirect-btg` | Pix Indirect BTG | | `plugin-br-bank-transfer` | Bank Transfer | Otros productos listados en la matriz de habilitación, como Tracer, Flowker y Fetcher, actualmente no definen nombres estándar de aplicaciones M2M en el seed de Access Manager. No crees aplicaciones con nombres fuera de este catálogo a menos que tu entorno tenga un conjunto de permisos personalizado para esa aplicación. ## 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. 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) para el usuario y el método MFA. 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) y [Verificar el desafío de MFA](/es/reference/access-manager/verify-mfa-login) antes de recibir access tokens utilizables. ## Información de usuario y control de sesión *** Una vez que un usuario está activo, algunos endpoints te ayudan a inspeccionar y controlar la 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. Cuando necesitas terminar una sesión antes de tiempo y revocar sus tokens activos, llama a [Finalizar sesión del usuario](/es/reference/access-manager/end-user-session). ## 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 de trabajo de la API es idéntico en despliegues single-tenant y multi-tenant. Lo único que cambia es de dónde obtiene Access Manager el alcance 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. * 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. Para los flujos normales de usuario, grupo, aplicación, token y permisos, el bearer token es tu única fuente del alcance del tenant.