Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Patrones de autenticación compatibles
AgentCore Identity admite dos patrones de autenticación principales que abordan diferentes casos de uso de agentes. La comprensión de estos patrones le ayudará a elegir el enfoque correcto para la implementación específica de su agente.
Para ver ejemplos detallados de cómo se aplican estos patrones a sectores y tipos de agentes específicos, consulte Ejemplos de casos de uso.
Temas
User-delegated acceso (concesión del código de autorización de OAuth 2.0)
El flujo de concesión de códigos de autorización de OAuth 2.0 permite a los agentes acceder a los datos específicos del usuario con el consentimiento explícito del usuario. Este patrón es esencial cuando los agentes necesitan acceder a datos personales o realizar acciones en nombre de usuarios específicos. El flujo incluye una etapa de consentimiento del usuario en la que el propietario del recurso (usuario) autoriza explícitamente al agente a acceder a sus datos dentro de ámbitos específicos.
Características clave
-
Requiere el consentimiento explícito del usuario mediante un mensaje de autorización
-
Proporciona acceso a datos y recursos específicos del usuario
-
Mantiene una separación clara entre la identidad del agente y la autorización del usuario
-
Admite alcances detallados que limitan los datos a los que puede acceder el agente
Ejemplo: un agente de productividad necesita acceder al Google Calendar de un usuario para programar reuniones, a Gmail para enviar correos electrónicos y a Google Drive para almacenar documentos. El agente utiliza el código de autorización de OAuth 2.0 para obtener el consentimiento del usuario para cada servicio, con alcances específicos que limitan el acceso solo a los datos necesarios. El usuario autoriza explícitamente al agente a través de la pantalla de consentimiento de Google, e AgentCore Identity almacena de forma segura las credenciales resultantes para usarlas en el futuro.
Este patrón es ideal para los agentes de asistencia personal, los agentes del servicio de atención al cliente y cualquier situación en la que los agentes necesiten acceder a datos específicos de los usuarios en varios servicios. Para ver ejemplos detallados de sectores específicos, consulte Agentes de asistencia personal y Agentes de servicio al cliente.
Machine-to-machine autenticación (concesión de credenciales de cliente de OAuth 2.0)
El flujo de concesión de credenciales de cliente de OAuth 2.0 permite la autenticación directa entre sistemas sin la interacción del usuario. Este patrón es adecuado cuando los agentes necesitan acceder a recursos que no son específicos del usuario o cuando los agentes actúan por sí mismos con el consentimiento de un usuario preautorizado.
Características clave
-
No se requiere la interacción ni el consentimiento del usuario
-
El agente se autentica directamente en los servidores de recursos mediante sus propias credenciales
-
Adecuado para procesos en segundo plano, tareas programadas y operaciones a nivel de sistema
-
Los permisos se definen a nivel de agente y no por usuario
Escenario de ejemplo: un agente de procesamiento de datos empresarial necesita recopilar datos de varios sistemas internos, procesarlos y almacenar los resultados en un almacén de datos. El agente utiliza las credenciales de cliente de OAuth 2.0 que se otorgan para autenticarse directamente en cada sistema utilizando su propia identidad y permisos preconfigurados. No es necesaria la interacción del usuario y el agente puede funcionar cuando los agentes actúan por sí mismos con el consentimiento preautorizado del usuario en intervalos programados.
Este patrón es ideal para los agentes de automatización empresarial, los flujos de trabajo de procesamiento de datos y la DevOps automatización. Para ver ejemplos detallados de sectores específicos, consulte Agentes de automatización empresarial, Agentes de procesamiento y análisis de datos y Desarrollo y DevOps agentes.
On-behalf-of intercambio de tokens (intercambio de tokens de OAuth 2.0)
On-behalf-of El intercambio de tokens (OBO) permite a los agentes acceder a los servidores de recursos intermedios en nombre de un usuario ya autenticado. El agente intercambia el token de usuario entrante por un nuevo token de acceso dirigido al público a través de un proveedor de credenciales saliente, vinculando tanto la identidad del usuario como la identidad del agente al token resultante. Los servicios intermedios pueden entonces tomar decisiones de autorización basándose en ambas identidades, sin necesidad de que el usuario pase por otro flujo de consentimiento.
Características clave
-
Sin consentimiento adicional del usuario: el token de usuario entrante se intercambia directamente por un token de acceso descendente
-
Propaga la identidad del usuario y la identidad del agente (o de la carga de trabajo) en varios saltos, lo que proporciona a cada servicio descendente el contexto necesario para tomar sus propias decisiones de autorización
-
Admite el intercambio de tokens estándar (RFC 8693
) o la concesión de autorizaciones de JWT (RFC 7523), según el proveedor de identidad
Ejemplo: acceder a una aplicación empresarial por usuario: una empresa tiene una aplicación interna de recursos humanos que impone el control de acceso por usuario; cada empleado solo puede ver sus propios datos de compensación y beneficios. La empresa quiere permitir que los empleados consulten esta aplicación a través de un agente de inteligencia artificial, sin flexibilizar ninguna de las políticas de acceso existentes.
-
Mike (administrador de identidad) configura la aplicación de RRHH como proveedor de credenciales de OAuth en AgentCore Identity, incluido el modo de intercambio de tokens OBO. Una vez configurada, no es necesario aprovisionarla por usuario: cualquier empleado que pueda autenticarse ante el agente puede acceder a la aplicación de RRHH a través de ella.
-
Bob (agente desarrollador) añade una herramienta que llama a la aplicación de RRHH. No escribe ninguna lógica de intercambio de tokens ni maneja los secretos de los clientes. Llama
GetResourceOauth2Tokencon el token de acceso a la carga de trabajo e AgentCore Identity devuelve un token con alcance descendente. Bob se centra en lo que hace el agente con los datos, no en cómo se autorizan. -
Sarah (usuaria final) inicia sesión con el agente y le pide que consulte su resumen de beneficios. No se le pide que inicie sesión por segunda vez. Entre bastidores, AgentCore Identity intercambia el token entrante de Sarah por un token de acceso descendente que contiene su identidad. La aplicación de recursos humanos aplica sus políticas de acceso existentes y solo devuelve los datos de Sarah, los mismos datos que vería si accediera directamente a la aplicación.
Este patrón es ideal para los agentes empresariales que utilizan varios servicios de reconocimiento de identidad en un único dominio de confianza. Para obtener más información sobre los tipos de concesión, la configuración y los proveedores de identidad compatibles, consulte el intercambio de tokens. On-behalf-of
Cómo elegir el patrón de autenticación correcto
Al diseñar su estrategia de autenticación de agentes, tenga en cuenta estos factores para determinar qué patrón es el más adecuado:
| Factor | User-delegated acceso (concesión del código de autorización de OAuth 2.0) | Machine-to-machine autenticación (concesión de credenciales de cliente de OAuth 2.0) | On-behalf-of intercambio de tokens (intercambio de tokens de OAuth 2.0) |
|---|---|---|---|
|
Propiedad de los datos |
User-specific datos (correos electrónicos, documentos, calendarios personales) |
Datos propiedad del sistema o de la organización (análisis, registros, recursos compartidos) |
User-specific datos, cuando el usuario ya está autenticado ante el agente |
|
Interacción del usuario |
El usuario está presente y puede dar su consentimiento |
No se requiere ni está disponible la interacción del usuario |
El usuario ya está autenticado ante el agente; no hay un nuevo aviso de consentimiento |
|
Tiempo de operación |
Operaciones interactivas en tiempo real |
Operaciones en segundo plano, programadas o por lotes |
Operaciones interactivas y en tiempo real iniciadas por un usuario autenticado |
|
Ámbito de los permisos |
Los permisos varían según el usuario y sus opciones de consentimiento |
Permisos coherentes definidos a nivel de agente |
Permisos derivados del token de usuario entrante y de la política de proveedores intermedios |
Muchas implementaciones de agentes requerirán todos los patrones para diferentes aspectos de su funcionalidad. Por ejemplo, un agente del servicio de atención al cliente puede utilizar el acceso delegado por el usuario para recuperar los datos de un cliente específico y, al mismo tiempo, utilizar la autenticación de máquina a máquina para acceder a las bases de conocimiento y los sistemas internos de la empresa. El mismo agente también puede utilizar el intercambio de tokens en nombre del usuario para propagar la identidad del usuario a los servicios intermedios que exigen la autorización por usuario, sin tener que volver a preguntar al usuario. AgentCore La identidad admite todos los patrones simultáneamente, lo que permite a los agentes utilizar el mecanismo de autenticación más adecuado para cada recurso al que necesiten acceder.
Todos los patrones de autenticación se benefician de las capacidades principales de AgentCore Identity:
-
Almacenamiento seguro de credenciales sin exponer los secretos al código del agente
-
Interfaces de autenticación coherentes en varios tipos de recursos
-
Registro de auditoría completo para garantizar la seguridad y el cumplimiento
-
Fine-grained controles de acceso basados en la identidad y el contexto
-
Integración simplificada a través del AgentCore SDK
