Patrones de autenticación compatibles
AgentCore Identity admite dos patrones de autenticación principales que abordan diferentes casos de uso de agentes. Comprender estos patrones le ayudará a elegir el enfoque correcto para la implementación específica de sus agentes.
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 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 un paso de consentimiento del usuario en el 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 una solicitud 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 ámbitos detallados que limitan los datos a los que puede acceder el agente
Ejemplo de escenario: un agente de productividad necesita acceder al calendario de Google de un usuario para programar reuniones, a su Gmail para enviar correos electrónicos y a Google Drive para almacenar documentos. El agente utiliza el código de autorización otorgado por OAuth 2.0 para obtener el consentimiento del usuario para cada servicio, con ámbitos específicos que limitan el acceso únicamente 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 asistentes personales, los agentes de servicio al cliente y cualquier situación en la que los agentes necesiten acceder a datos específicos del usuario en varios servicios. Para ver ejemplos detallados específicos del sector, consulte Agentes asistentes personales 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 preautorizado del usuario.
Características clave
-
No se requiere la interacción ni el consentimiento del usuario
-
El agente se autentica directamente en los servidores de recursos con sus propias credenciales
-
Adecuado para procesos en segundo plano, tareas programadas y operaciones a nivel del sistema
-
Los permisos se definen a nivel de agente y no por usuario
Ejemplo de escenario: 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 otorgadas por OAuth 2.0 para autenticarse directamente en cada sistema con su propia identidad y permisos preconfigurados. No se requiere 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 específicos del sector, consulte Agentes de automatización empresarial, Agentes de procesamiento y análisis de datos y DevOps Agentes y desarrollo.
On-behalf-of intercambio de fichas (intercambio de fichas 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 orientado al público a través de un proveedor de credenciales salientes, lo que vincula la identidad del usuario y la identidad del agente al token resultante. De este modo, los servicios intermedios pueden tomar decisiones de autorización en función de 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 fichas estándar (RFC 8693
) o la concesión de autorizaciones JWT (RFC 7523 ), según el proveedor de identidad
Ejemplo de escenario: 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 prestaciones. 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 identidades) configura la aplicación de RRHH como un proveedor de credenciales de OAuth en AgentCore Identity, incluido el modo de intercambio de fichas de OBO. Una vez configurada, no es necesario realizar ningún aprovisionamiento 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 llamada aplicación de RRHH. No escribe ninguna lógica de intercambio de fichas ni maneja los secretos de los clientes. Llama
GetResourceOauth2Tokencon el token de acceso a la carga de trabajo e AgentCore Identity devuelve un token descendente con un alcance determinado. Bob se centra en lo que el agente hace con los datos, no en cómo los autoriza. -
Sarah (usuaria final) inicia sesión en el agente y le pide que le muestre 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 intermedio que contiene su identidad. La aplicación de RRHH aplica sus políticas de acceso actuales y devuelve solo 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 con reconocimiento de identidad en un único dominio de confianza. Para obtener información detallada sobre los tipos de concesión, la configuración y los proveedores de identidad compatibles, consulta el intercambio de fichas. On-behalf-of
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 fichas (intercambio de fichas 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, donde el usuario ya está autenticado ante el agente |
|
Interacción con el usuario |
El usuario está presente y puede dar su consentimiento |
No se requiere ni está disponible la interacción del usuario |
El usuario ya se ha autenticado ante el agente; no hay ninguna nueva solicitud de consentimiento |
|
Tiempo de operación |
Operaciones interactivas en tiempo real |
Operaciones en segundo plano, programadas o por lotes |
Operaciones interactivas 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 distintos aspectos de su funcionalidad. Por ejemplo, un agente de servicio 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 fichas 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 de forma simultánea, 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 integral para garantizar la seguridad y el cumplimiento
-
Fine-grained controles de acceso basados en la identidad y el contexto
-
Integración simplificada mediante el AgentCore SDK
