Modelli di autenticazione supportati
AgentCore Identity supporta due modelli di autenticazione principali che riguardano diversi casi d'uso degli agenti. La comprensione di questi modelli vi aiuterà a scegliere l'approccio giusto per l'implementazione specifica del vostro agente.
Per esempi dettagliati di come questi modelli si applicano a settori e tipi di agenti specifici, consulta Esempi di utilizzo.
Argomenti
User-delegated accesso (concessione del codice di autorizzazione OAuth 2.0)
Il flusso di concessione del codice di autorizzazione OAuth 2.0 consente agli agenti di accedere a dati specifici dell'utente con il consenso esplicito dell'utente. Questo modello è essenziale quando gli agenti devono accedere ai dati personali o eseguire azioni per conto di utenti specifici. Il flusso include una fase di consenso dell'utente in cui il proprietario della risorsa (utente) autorizza esplicitamente l'agente ad accedere ai propri dati entro ambiti specifici.
Caratteristiche chiave
-
Richiede il consenso esplicito dell'utente tramite una richiesta di autorizzazione
-
Fornisce accesso a dati e risorse specifici dell'utente
-
Mantiene una chiara separazione tra l'identità dell'agente e l'autorizzazione dell'utente
-
Supporta ambiti dettagliati che limitano i dati a cui l'agente può accedere
Scenario di esempio: un addetto alla produttività deve accedere a Google Calendar di un utente per pianificare riunioni, a Gmail per inviare e-mail e a Google Drive per archiviare documenti. L'agente utilizza la concessione del codice di autorizzazione OAuth 2.0 per ottenere il consenso dell'utente per ciascun servizio, con ambiti specifici che limitano l'accesso solo ai dati necessari. L'utente autorizza esplicitamente l'agente tramite la schermata di consenso di Google e AgentCore Identity archivia in modo sicuro le credenziali risultanti per utilizzi futuri.
Questo modello è ideale per gli assistenti personali, gli agenti del servizio clienti e per qualsiasi scenario in cui gli agenti abbiano bisogno di accedere a dati specifici dell'utente su più servizi. Per esempi dettagliati specifici del settore, consulta Agenti assistenti personali e Agenti del servizio clienti.
Machine-to-machine autenticazione (concessione delle credenziali del client OAuth 2.0)
Il flusso di concessione delle credenziali del client OAuth 2.0 consente l'autenticazione diretta tra i sistemi senza l'interazione dell'utente. Questo modello è appropriato quando gli agenti devono accedere a risorse che non sono specifiche dell'utente o quando gli agenti agiscono autonomamente con il consenso dell'utente preautorizzato.
Caratteristiche chiave
-
Non è richiesta l'interazione o il consenso dell'utente
-
L'agente si autentica direttamente con i server di risorse utilizzando le proprie credenziali
-
Adatto per processi in background, attività pianificate e operazioni a livello di sistema
-
Le autorizzazioni sono definite a livello di agente anziché per utente
Scenario di esempio: un agente di elaborazione dati aziendale deve raccogliere dati da più sistemi interni, elaborarli e archiviare i risultati in un data warehouse. L'agente utilizza la concessione delle credenziali del client OAuth 2.0 per autenticarsi direttamente con ciascun sistema utilizzando la propria identità e le proprie autorizzazioni preconfigurate. Non è richiesta alcuna interazione da parte dell'utente e l'agente può operare quando gli agenti agiscono autonomamente con il consenso dell'utente preautorizzato a intervalli pianificati.
Questo modello è ideale per gli agenti di automazione aziendale, i flussi di lavoro di elaborazione dati e l'automazione. DevOps Per esempi dettagliati specifici del settore, consulta Agenti di automazione aziendale, Agenti di elaborazione e analisi dei dati e Sviluppo e agenti. DevOps
On-behalf-of scambio di token (scambio di token OAuth 2.0)
On-behalf-of (OBO) Lo scambio di token consente agli agenti di accedere ai server di risorse downstream per conto di un utente già autenticato. L'agente scambia il token utente in entrata con un nuovo token di accesso destinato al pubblico tramite un provider di credenziali in uscita, associando sia l'identità dell'utente che l'identità dell'agente al token risultante. I servizi downstream possono quindi prendere decisioni di autorizzazione in base a entrambe le identità, senza richiedere all'utente di passare attraverso un altro flusso di consenso.
Caratteristiche chiave
-
Nessun consenso utente aggiuntivo: il token utente in entrata viene scambiato direttamente con un token di accesso a valle
-
Propaga sia l'identità dell'utente che l'identità dell'agente (o del carico di lavoro) su più hop, fornendo a ciascun servizio a valle il contesto necessario per prendere le proprie decisioni di autorizzazione
-
Supporta lo scambio di token standard (RFC 8693
) o la concessione di autorizzazione JWT (RFC 7523), a seconda del provider di identità
Scenario di esempio: accesso a un'applicazione aziendale per utente: un'azienda dispone di un'applicazione HR interna che impone il controllo degli accessi per utente: ogni dipendente può visualizzare solo i propri dati su retribuzioni e benefit. L'azienda desidera consentire ai dipendenti di interrogare questa applicazione tramite un agente di intelligenza artificiale, senza allentare nessuna delle politiche di accesso esistenti.
-
Mike (identity admin) configura l'applicazione HR come provider di credenziali OAuth in AgentCore Identity, inclusa la modalità di scambio di token OBO. Una volta configurata, non è necessario alcun provisioning per utente: qualsiasi dipendente in grado di autenticarsi presso l'agente può accedere all'applicazione HR tramite essa.
-
Bob (agente sviluppatore) aggiunge uno strumento che richiama l'applicazione HR. Non scrive alcuna logica di scambio di token né gestisce i segreti dei clienti. Chiama
GetResourceOauth2Tokencon il token di accesso al carico di lavoro e AgentCore Identity restituisce un token downstream con ambito. Bob si concentra su ciò che l'agente fa con i dati, non su come vengono autorizzati. -
Sarah (utente finale) accede all'agente e gli chiede di recuperare il riepilogo dei vantaggi. Non le viene richiesto di accedere una seconda volta. Dietro le quinte, AgentCore Identity scambia il token in entrata di Sarah con un token di accesso a valle che riporta la sua identità. L'applicazione HR applica le politiche di accesso esistenti e restituisce solo i dati di Sarah, gli stessi dati che vedrebbe se accedesse direttamente all'applicazione.
Questo modello è ideale per gli agenti aziendali che utilizzano più servizi con riconoscimento dell'identità in un unico dominio di fiducia. Per un'analisi approfondita dei tipi di concessione, della configurazione e dei provider di identità supportati, consulta Token Exchange. On-behalf-of
Scegliere il modello di autenticazione giusto
Nel progettare la strategia di autenticazione degli agenti, considerate questi fattori per determinare il modello più appropriato:
| Factor | User-delegated accesso (concessione del codice di autorizzazione OAuth 2.0) | Machine-to-machine autenticazione (concessione delle credenziali del client OAuth 2.0) | On-behalf-of scambio di token (scambio di token OAuth 2.0) |
|---|---|---|---|
|
Proprietà dei dati |
User-specific dati (e-mail, documenti, calendari personali) |
dati di proprietà del sistema o dell'organizzazione (analisi, registri, risorse condivise) |
User-specific dati, in cui l'utente è già autenticato presso l'agente |
|
Interazione con l'utente |
L'utente è presente e può fornire il consenso |
Nessuna interazione dell'utente richiesta o disponibile |
L'utente è già autenticato presso l'agente; nessuna nuova richiesta di consenso |
|
Tempistica delle operazioni |
Operazioni interattive in tempo reale |
Operazioni in background, pianificate o in batch |
Operazioni interattive in tempo reale avviate da un utente autenticato |
|
Ambito di autorizzazione |
Le autorizzazioni variano in base all'utente e alle relative scelte di consenso |
Autorizzazioni coerenti definite a livello di agente |
Autorizzazioni derivate dal token utente in entrata e dalla politica del provider a valle |
Molte implementazioni di agenti richiederanno tutti i modelli per diversi aspetti della loro funzionalità. Ad esempio, un agente del servizio clienti potrebbe utilizzare l'accesso delegato dall'utente per recuperare i dati di un cliente specifico utilizzando l'autenticazione da macchina a macchina per accedere alle knowledge base aziendali e ai sistemi interni. Lo stesso agente può anche utilizzare lo scambio di token per conto dell'utente per diffondere l'identità dell'utente ai servizi a valle che applicano l'autorizzazione per utente, senza richiedere nuovamente l'autorizzazione all'utente. AgentCore Identity supporta tutti i modelli contemporaneamente, consentendo agli agenti di utilizzare il meccanismo di autenticazione più appropriato per ogni risorsa a cui devono accedere.
Tutti i modelli di autenticazione traggono vantaggio dalle funzionalità principali di AgentCore Identity:
-
Archiviazione sicura delle credenziali senza rivelare segreti al codice dell'agente
-
Interfacce di autenticazione coerenti su più tipi di risorse
-
Registrazione completa degli audit per la sicurezza e la conformità
-
Fine-grained controlli degli accessi basati su identità e contesto
-
Integrazione semplificata tramite SDK AgentCore
