Amazon AWS aggiunge Private Key JWT ad AgentCore Identity, sostituendo i segreti condivisi con il controllo KMS

Amazon AWS ha aggiunto l’autenticazione Private Key JWT ad AgentCore Identity, offrendo agli agenti automatizzati una nuova alternativa ai client secret OAuth a lunga durata. La modifica orienta l’autenticazione del client verso asserzioni firmate e di breve durata, supportate da AWS Key Management Service. Crea inoltre una registrazione più chiara di ogni richiesta di firma in AWS CloudTrail.

Questa combinazione è importante perché un agente autonomo può richiedere token molto più frequentemente di una tradizionale applicazione destinata ai dipendenti. Un client secret copiato può restare utilizzabile finché qualcuno non lo ruota o revoca. Un’asserzione Private Key JWT scade rapidamente e richiede l’accesso a una chiave di firma protetta per ogni nuova richiesta.

La questione centrale non riguarda semplicemente chiavi contro password. Amazon Bedrock AgentCore Identity promette ora un controllo più forte senza costringere gli sviluppatori a creare e gestire un proprio servizio di firma. Il mantenimento di questa promessa dipende dalla compatibilità del provider di identità, dalla configurazione precisa delle claim, dai permessi KMS e da una copertura di audit completa.

Amazon AWS porta l’autenticazione del client OAuth in KMS

La modifica importante è che AgentCore Identity può autenticare un client OAuth senza archiviare un client secret riutilizzabile.

Nel nuovo modello descritto nell’annuncio di Private Key JWT, AgentCore Identity costruisce un JSON Web Token e lo firma tramite AWS KMS. Il provider di identità verifica tale firma utilizzando la corrispondente chiave pubblica.

La chiave privata rimane all’interno di KMS. Un agente, un processo applicativo o un amministratore non deve esportare la chiave in un file di configurazione, un’immagine container, una variabile d’ambiente o un archivio segreti separato.

Il JWT firmato è un’asserzione client, ovvero dimostra l’identità del client OAuth a un server di autorizzazione. Non è l’access token infine presentato a un’API. Il server di autorizzazione convalida l’asserzione prima di emettere quell’access token.

Questa distinzione è facile da trascurare. L’autenticazione del client OAuth risponde alla domanda se l’applicazione che richiede un token sia il client registrato. L’OAuth grant determina quale autorità rappresenti il token risultante e quali autorizzazioni riceva.

Private Key JWT può quindi operare in più di un grant flow. AgentCore Identity supporta l’accesso delegato dall’utente tramite l’authorization code grant e l’accesso machine-to-machine tramite client credentials. I suoi più ampi modelli di autenticazione comprendono anche configurazioni di token exchange on-behalf-of.

Per una richiesta delegata dall’utente, una persona autorizza prima l’accesso tramite il provider di identità. AgentCore Identity autentica quindi il client OAuth quando scambia l’authorization code con i token. L’approvazione dell’utente e l’identità del client restano controlli distinti.

Per una richiesta machine-to-machine, nessun utente completa una schermata di consenso interattiva. L’agente richiede un access token sotto la propria autorità applicativa. Private Key JWT autentica tale applicazione durante lo scambio client credentials.

Questo rende la funzionalità rilevante oltre il login. È rivolta all’accesso in uscita degli agenti a API aziendali, servizi software e altre risorse protette. Si tratta proprio delle connessioni in cui una credenziale statica può diventare una passività operativa.

AgentCore Identity agisce già da intermediario tra agenti, server di autorizzazione e resource server. Recupera le credenziali mantenendo segreti a lungo termine e refresh token lontani dal codice degli agenti. Private Key JWT estende questo confine al materiale di autenticazione del client OAuth.

Il percorso della richiesta ora presenta diverse fasi esplicite. L’agente chiede ad AgentCore Identity un accesso autorizzato. AgentCore Identity crea un’asserzione a durata limitata, chiama KMS per firmarla e la invia al token endpoint del provider di identità.

Il provider di identità verifica la firma rispetto alla chiave pubblica registrata. Valuta inoltre le claim che identificano il client, l’audience, l’ora di emissione e la scadenza. Se tali verifiche riescono, il provider restituisce un access token tramite AgentCore Identity.

Questo design non elimina la fiducia. La sposta nelle policy KMS, nei ruoli IAM, nella configurazione OAuth e nella registrazione della chiave pubblica presso il provider di identità. Questi controlli sono più granulari di una stringa copiata, ma introducono anche più punti in cui una mancata corrispondenza può bloccare l’autenticazione.

Come Private Key JWT modifica il modello dei segreti

Private Key JWT riduce la dipendenza dai segreti condivisi, ma la sua sicurezza dipende dal controllo di chi può chiedere a KMS di firmare.

L’autenticazione tradizionale del client OAuth utilizza comunemente client_secret_basic o client_secret_post. Entrambi i metodi inviano un client ID e un segreto condiviso al server di autorizzazione. La differenza è se tali credenziali compaiano in un’intestazione HTTP Basic oppure nel corpo della richiesta.

La documentazione AWS descrive HTTP Basic come metodo predefinito per i provider AgentCore Identity personalizzati. Il segreto rimane riutilizzabile fino alla rotazione, alla scadenza o alla revoca. Ogni sistema che ne conserva una copia entra a far parte del perimetro di sicurezza della credenziale.

Private Key JWT sostituisce questo modello simmetrico con una coppia di chiavi asimmetriche. Una parte controlla la chiave privata di firma, mentre il provider di identità conserva soltanto la chiave pubblica di verifica. L’esposizione della chiave pubblica non consente a un attaccante di generare asserzioni valide.

L’approccio segue il profilo OAuth JWT, che definisce i JWT per l’autenticazione dei client e gli authorization grant. La richiesta del token include un’asserzione client e la identifica come un’asserzione JWT bearer.

Un’asserzione tipica contiene una claim issuer che identifica il client, una claim subject per quel client e una claim audience che indica il token endpoint. Include anche gli orari di scadenza e di emissione. Un identificatore JWT univoco può aiutare un provider di identità a rilevare tentativi di replay.

Questi campi non sono metadati decorativi. Un’audience errata può rendere non valido un JWT correttamente firmato. Una differenza di orario può indurre il provider a rifiutare un’asserzione come prematura o scaduta.

Private Key JWT non garantisce inoltre automaticamente la protezione dai replay. RFC 7523 lascia alcune difese contro il replay alle policy di implementazione. I provider di identità necessitano di limiti di durata adeguati e, dove supportato, del tracciamento delle asserzioni univoche.

Finestre di scadenza brevi riducono l’utilità di un’asserzione intercettata. Non proteggono un sistema in cui un attaccante ha il permesso di invocare ripetutamente la chiave di firma. Per questo la key policy KMS e i permessi IAM diventano il livello di applicazione principale.

AWS KMS rappresenta una chiave asimmetrica come una coppia collegata di chiave pubblica e privata. Per le chiavi di firma, il componente privato resta protetto all’interno del servizio. Il componente pubblico può essere scaricato e registrato presso un provider di identità esterno.

KMS supporta diversi tipi di chiavi asimmetriche, incluse chiavi RSA e a curva ellittica per la firma e la verifica. Il tipo di chiave e l’algoritmo scelti devono corrispondere a quanto accettato dal provider di identità.

AgentCore Identity necessita dell’autorizzazione a utilizzare la chiave configurata per la firma. AWS afferma che i chiamanti dell’operazione KMS Sign richiedono l’autorizzazione kms:Sign tramite la key policy. Il servizio utilizza quindi il componente privato senza restituirlo.

Si tratta di un miglioramento significativo del contenimento. Una perdita di configurazione che esponga un ARN della chiave non rivela materiale della chiave privata. Un attaccante avrebbe comunque bisogno di credenziali AWS e di un’autorizzazione effettiva per invocare la chiave.

Tuttavia, il permesso di firmare rimane sensibile. Un ruolo con accesso kms:Sign ampio potrebbe potenzialmente richiedere firme al di fuori del percorso del carico di lavoro previsto. I team dovrebbero vincolare i permessi ai corretti ruoli di esecuzione AgentCore ed evitare accessi wildcard generici.

La modifica influisce anche sulla rotazione. Con un segreto condiviso, entrambe le parti devono sostituire lo stesso valore confidenziale. Con l’autenticazione asimmetrica, i team possono introdurre una nuova chiave pubblica presso il provider di identità mantenendo il precedente verificatore durante una transizione controllata.

Questa sovrapposizione può ridurre i tempi di inattività, a condizione che il provider di identità supporti più chiavi attive. Se accetta una sola chiave pubblica, la rotazione richiede comunque una tempistica coordinata. Private Key JWT modifica il materiale da ruotare, non la necessità di un processo di rotazione testato.

I grant flow supportati servono identità di agenti diverse

Private Key JWT autentica il client OAuth, mentre il grant selezionato determina se un agente agisce per sé stesso o per un utente.

L’authorization code grant è adatto agli agenti che accedono alle risorse per conto di una persona. Un utente effettua l’accesso tramite un provider di identità e approva le autorizzazioni richieste. Il server di autorizzazione restituisce un codice che il client scambia con i token.

Durante questo scambio, AgentCore Identity usa l’asserzione Private Key JWT per dimostrare che sia il client registrato a effettuare la richiesta. L’asserzione non sostituisce il consenso dell’utente. Rafforza l’autenticazione al token endpoint.

Questo flusso è adatto a un agente che legge il calendario di un utente, cerca i record autorizzati di un dipendente o aggiorna un sistema di gestione clienti entro i permessi delegati. L’accesso risultante resta associato all’utente e agli scope approvati.

Il client credentials grant affronta un caso diverso. Qui, il carico di lavoro agisce per sé stesso senza un utente interattivo. Un agente pianificato potrebbe chiamare un’API interna di inventario, elaborare avvisi di servizio o recuperare dati operativi approvati.

Private Key JWT autentica quel client macchina prima che il server di autorizzazione emetta un token applicativo. Poiché non è presente una persona, l’identità del client, gli scope del token e la policy di autorizzazione a valle sostengono una parte maggiore dell’onere di sicurezza.

Le organizzazioni non dovrebbero considerare i due grant come opzioni di deployment intercambiabili. L’uso di client credentials per un’attività che dovrebbe preservare l’identità dell’utente può oscurare la responsabilità. L’uso di un flusso delegato per il lavoro di un servizio in background può creare dipendenze fragili da account individuali.

L’accesso on-behalf-of introduce un’ulteriore variante. Un agente riceve la prova di un’identità utente esistente e la scambia con un token adatto a un’altra risorsa. Il flusso deve preservare la relazione tra utente, agente e servizio di destinazione.

La documentazione di AgentCore Identity descrive sia il token exchange standard sia gli approcci di authorization grant basati su JWT per questi casi. Il supporto dipende comunque dal server di autorizzazione esterno e dalle sue regole di token exchange.

Private Key JWT può autenticare il client che partecipa a questo scambio. Non decide se il token utente in ingresso sia valido né se la delega richiesta debba essere consentita. Tali decisioni restano ai sistemi di identità e autorizzazione pertinenti.

Questa separazione è uno dei punti architetturali più forti della funzionalità. I team possono scegliere un grant in base all’autorità necessaria all’agente, quindi scegliere Private Key JWT in base al modo in cui il client deve dimostrare la propria identità.

Evidenzia inoltre perché un’unica “credenziale dell’agente” sia un modello mentale poco sicuro. Un agente può avere un’identità di carico di lavoro, operare per un utente, chiamare diversi resource server e utilizzare token diversi per ciascuna destinazione.

Il token di accesso al workload di AgentCore Identity aggiunge un ulteriore livello. AWS afferma che questo token può includere l’identità dell’agente e quella dell’utente finale quando l’agente richiede credenziali al vault. AgentCore Runtime può fornirlo automaticamente agli agenti ospitati.

Quel token di workload autorizza l’accesso ad AgentCore Identity. Il token di accesso OAuth esterno autorizza l’accesso all’API di destinazione. L’asserzione Private Key JWT autentica il client OAuth durante l’emissione del token.

In una singola transazione end-to-end possono quindi comparire tre token, ciascuno con una funzione diversa. Confonderli può portare a convalide errate, logging eccessivo o esposizione accidentale.

Le revisioni di sicurezza dovrebbero associare ogni token al relativo emittente, pubblico, detentore, durata e destinazione. Dovrebbero inoltre individuare quale componente può rinnovarlo o sostituirlo. Questo esercizio intercetta errori di progettazione che i diagrammi a livello di prodotto possono nascondere.

La pressione competitiva più ampia ricade sulle integrazioni degli agenti basate su segreti. I client secret statici sono familiari e ampiamente supportati, ma scalano male quando numerosi workload autonomi richiedono autorizzazioni indipendenti e tracciabilità di audit.

Private Key JWT aumenta l’onere di configurazione riducendo al contempo la duplicazione delle credenziali. Per i team che già gestiscono AWS IAM, KMS e CloudTrail, questo compromesso può risultare interessante. Per implementazioni più piccole, la superficie di policy aggiuntiva può superare il beneficio immediato.

Configurare la catena di trust richiede più della selezione di un metodo

La configurazione riesce solo quando KMS, IAM, AgentCore Identity e il provider di identità esterno concordano sugli stessi dettagli crittografici e OAuth.

Il primo requisito è una chiave KMS asimmetrica configurata per la firma e la verifica. Le chiavi di crittografia non possono svolgere questo compito. La specifica della chiave e l’algoritmo di firma devono corrispondere a una combinazione accettata dal provider di identità di destinazione.

AWS KMS espone la parte pubblica di una chiave di firma asimmetrica. I team registrano questa chiave pubblica presso il proprio provider di identità, direttamente oppure tramite una configurazione JSON Web Key supportata.

Il provider di identità deve associare la chiave al client OAuth corretto. Deve inoltre supportare Private Key JWT al proprio endpoint token. Le interfacce di registrazione e gli algoritmi accettati variano tra provider, quindi questo passaggio resta specifico del provider.

Successivamente, gli amministratori creano o aggiornano un provider di credenziali OAuth personalizzato nella console Amazon Bedrock AgentCore. La configurazione richiede le informazioni di discovery del provider, l’identificatore del client, l’ARN della chiave KMS e l’algoritmo di firma.

La discovery OAuth consente ad AgentCore Identity di individuare gli endpoint di autorizzazione e token dai metadati del provider. I team dovrebbero verificare che l’endpoint token individuato corrisponda al valore audience previsto dal provider di identità.

AgentCore Identity necessita inoltre dell’autorizzazione per invocare KMS. L’operazione di firma di KMS richiede una chiave con utilizzo SIGN_VERIFY e un algoritmo compatibile con quella chiave.

KMS accetta un messaggio non elaborato oppure un digest precalcolato, a seconda del tipo di messaggio selezionato. Un’implementazione JWT deve evitare il doppio hashing accidentale, poiché la verifica esterna presuppone il comportamento di hashing specificato dall’algoritmo.

Anche la configurazione dell’header JWT è importante. Il provider di identità può utilizzare un identificatore della chiave per selezionare la chiave pubblica appropriata. Un identificatore assente o errato diventa particolarmente problematico durante la rotazione, quando possono essere attive diverse chiavi pubbliche.

Le claim del payload richiedono altrettanta attenzione. L’emittente e il soggetto corrispondono comunemente all’ID del client OAuth. L’audience identifica normalmente l’endpoint token del server di autorizzazione, sebbene i requisiti del provider debbano determinare il valore esatto.

La scadenza dovrebbe restare breve. L’ora di emissione deve riflettere un orologio sincronizzato. Un identificatore univoco del token è prezioso quando il provider registra le asserzioni precedentemente accettate.

Dopo aver salvato il provider di credenziali, i team dovrebbero testare separatamente ogni grant previsto. Una richiesta client credentials riuscita non dimostra che lo scambio del codice di autorizzazione o il token exchange siano configurati correttamente.

I test dovrebbero iniziare con scope minimi. Se l’autenticazione riesce ma l’autorizzazione fallisce, la distinzione diventa più semplice da diagnosticare. Aggiungere autorizzazioni ampie per aggirare un errore può nascondere un problema di audience o di registrazione del client.

I team dovrebbero inoltre testare i percorsi negativi. Una richiesta firmata con la chiave errata dovrebbe fallire. Un’asserzione scaduta dovrebbe fallire. Un’audience errata e un chiamante KMS non autorizzato dovrebbero produrre ciascuno evidenze distinguibili.

È qui che il compromesso operativo diventa visibile. I segreti condivisi sono abbastanza semplici da indurre spesso i team a convalidare solo il percorso ideale. Private Key JWT offre confini più solidi, ma tali confini richiedono test espliciti.

La configurazione crea inoltre dipendenze tra team amministrativi. Un team di sicurezza cloud può essere responsabile delle policy KMS e IAM. Un team di identità può controllare il client OAuth e la registrazione della chiave pubblica.

I proprietari dell’applicazione configurano AgentCore Identity e determinano gli scope dei grant. I team di audit decidono quali record CloudTrail devono essere conservati e generare avvisi. Nessuna singola selezione nella console risolve queste questioni di responsabilità.

Un rollout utile inizia con un’integrazione non critica. I team possono documentare requisiti delle claim, risposte agli errori, passaggi di rotazione e responsabilità di escalation prima di applicare il metodo a molti agenti.

L’automazione dovrebbe seguire questa prima implementazione convalidata. I template di infrastruttura possono standardizzare le policy delle chiavi e le impostazioni dei provider di credenziali, ma non dovrebbero fare supposizioni sul comportamento del provider di identità.

Il risultato non è un sistema privo di segreti. I token esistono ancora, i server di autorizzazione mantengono ancora relazioni di trust e le autorizzazioni AWS restano credenziali. L’affermazione più circoscritta è più difendibile: il client OAuth non dipende più da un segreto condiviso e riutilizzabile.

CloudTrail trasforma ogni firma in un segnale di audit

La firma supportata da KMS offre ai difensori un evento lato AWS che possono correlare con le richieste di token e l’attività degli agenti.

AWS KMS si integra con CloudTrail, che registra le chiamate effettuate da utenti, ruoli e servizi AWS. Il suo logging di audit KMS include operazioni crittografiche e azioni di gestione delle chiavi.

Una transazione Private Key JWT dovrebbe quindi generare evidenze relative alla richiesta di firma KMS. L’evento può identificare l’operazione, la regione, l’ora, la chiave pertinente e il principal AWS o il contesto del servizio coinvolto.

Questo record, da solo, non contiene l’intera storia. CloudTrail mostra che un’identità AWS autorizzata ha richiesto una firma. I log del provider di identità esterno mostrano se ha accettato l’asserzione ed emesso un token.

I log di audit del servizio di destinazione mostrano cosa ha fatto il token di accesso risultante. Un’indagine efficace correla tutti e tre i livelli invece di trattare l’evento KMS come prova di accesso riuscito alle risorse.

CloudTrail può comunque rispondere a domande importanti. Gli investigatori possono cercare volumi di firma inattesi, richieste dal ruolo sbagliato, chiamate in una regione non approvata o attività che coinvolgono una chiave al di fuori della sua normale pianificazione.

I selettori di eventi configurati sono importanti. AWS classifica gli eventi KMS come eventi di gestione e i trail CloudTrail normalmente registrano l’attività di gestione. Gli amministratori possono tuttavia escludere esplicitamente gli eventi KMS.

AWS avverte che le operazioni KMS possono generare elevati volumi di eventi. Alcune organizzazioni li filtrano per controllare il volume di logging. Così facendo si possono eliminare proprio le evidenze di firma che rendono questo modello di autenticazione più semplice da sottoporre ad audit.

I team che adottano Private Key JWT dovrebbero rivedere le proprie impostazioni degli eventi di gestione. Dovrebbero confermare che l’attività KMS pertinente raggiunga il trail o l’event data store previsto.

Anche conservazione e ricercabilità sono importanti. La cronologia degli eventi è utile per indagini recenti, mentre un trail o un event data store CloudTrail Lake supporta analisi più lunghe. I record esportati possono inoltre alimentare sistemi di monitoraggio della sicurezza.

Una baseline dovrebbe distinguere il comportamento previsto di refresh dei token dalle anomalie. Un agente macchina in esecuzione continua può firmare asserzioni a cadenza regolare. Un flusso di lavoro delegato da un utente può creare picchi durante le sessioni attive.

Deviazioni rilevanti possono indicare un ciclo di tentativi, un errore di configurazione o un uso improprio delle credenziali. Firme ripetute seguite dal rifiuto dell’endpoint token potrebbero indicare un’audience errata, una chiave pubblica scaduta o un problema di orologio.

L’attività di firma senza richieste AgentCore corrispondenti merita un esame più approfondito. Lo stesso vale per l’emissione riuscita di token senza le chiamate downstream previste. Ogni modello identifica una diversa rottura nella catena di trust.

Gli eventi del ciclo di vita delle chiavi dovrebbero ricevere avvisi separati. La disabilitazione di una chiave di firma può interrompere ogni integrazione dipendente. Le modifiche alle policy possono ampliare silenziosamente chi è autorizzato a invocarla.

CloudTrail aiuta anche durante la rotazione. I team possono osservare se la vecchia chiave continua a ricevere richieste di firma dopo l’attivazione di una nuova chiave. L’attività continua può rivelare un provider di credenziali trascurato o una distribuzione ritardata.

La visibilità di audit resta tuttavia condizionale. I log devono essere abilitati, conservati, protetti e revisionati. Un evento registrato ma mai interrogato offre poca difesa pratica.

Gli eventi CloudTrail non convalidano nemmeno la ragione di business di una richiesta. Un agente correttamente autorizzato può comunque richiedere un token di accesso nel momento sbagliato o utilizzarlo per un’attività eccessivamente ampia.

Questa limitazione sposta l’attenzione verso la progettazione dell’autorizzazione. Private Key JWT può dimostrare che il client controlla l’accesso a una chiave di firma. Non può determinare se l’obiettivo dell’agente, lo strumento selezionato o l’operazione richiesta siano appropriati.

Le organizzazioni necessitano di restrizioni sugli scope, policy del resource server, controlli sui workload e monitoraggio comportamentale attorno alla prova crittografica. La firma è un segnale di alta qualità, non un sistema completo di governance degli agenti.

Cosa dovrebbero osservare le imprese dopo il lancio di Private Key JWT

Il prossimo test è stabilire se Private Key JWT diventerà un’impostazione operativa predefinita o resterà un’opzione avanzata per implementazioni gestite in modo rigoroso.

Il primo segnale è l’interoperabilità con i provider di identità. Un’adozione riuscita richiede che i provider accettino gli algoritmi di firma, le claim, il formato dell’audience e il metodo di registrazione della chiave pubblica selezionati.

AWS può semplificare il proprio lato dello scambio, ma non può standardizzare il flusso di lavoro amministrativo di ogni provider. Esempi chiari e specifici per provider ridurrebbero le implementazioni fallite e le soluzioni alternative non sicure.

Il secondo segnale è il comportamento di rotazione. Le imprese devono sapere se possono registrare chiavi pubbliche sovrapposte, aggiornare i provider AgentCore senza interruzioni e confermare la migrazione tramite i record di audit.

Una funzionalità che opera solo durante la configurazione iniziale risolve metà del problema. L’autenticazione in produzione richiede anche un recupero prevedibile quando una chiave viene disabilitata, sostituita o compromessa.

Il terzo segnale è l’adozione dell’audit. CloudTrail offre ai team accesso ai record di firma, ma le organizzazioni devono conservare gli eventi KMS e collegarli ai log del provider di identità e del resource server.

Indicazioni sul rilevamento renderebbero la funzionalità più utile. Tassi di firma elevati, principal non familiari, errori ripetuti e attività regionale inattesa sono candidati pratici per gli avvisi.

I team di sicurezza dovrebbero inoltre osservare i confini del modello di autorizzazioni di AgentCore Identity. La policy ideale consente a un workload di utilizzare una chiave di firma per un provider approvato senza concedere accesso alla firma non correlato.

Le chiavi cross-account aggiungono flessibilità, ma richiedono attente resource policy. AWS KMS supporta l’uso cross-account per la firma quando i chiamanti specificano l’ARN della chiave e ricevono le autorizzazioni necessarie.

Questa funzionalità può favorire una gestione centralizzata della sicurezza. Può anche creare dipendenze tra gli account applicativi e un account centrale per l'identità. Interruzioni del servizio o errori nelle policy dell'account centrale possono avere effetti su molti agenti.

Le aziende dovrebbero misurare i risultati operativi invece di presumere che il design crittografico garantisca il successo. Tra gli indicatori utili rientrano il carico di lavoro per la rotazione dei segreti, gli errori nelle richieste di token, i tentativi di firma non autorizzati e il tempo di ripristino dopo le modifiche alle chiavi.

Dovrebbero inoltre confrontare Private Key JWT con l'autenticazione JWT firmata da AWS IAM. La documentazione di AgentCore Identity descrive un metodo AWS_IAM_ID_TOKEN_JWT che utilizza un'attestazione emessa da IAM e richiede al server di autorizzazione di considerare AWS IAM affidabile.

Entrambi gli approcci si allontanano dai segreti client condivisi, ma stabiliscono la fiducia in modo diverso. Private Key JWT richiede al provider di identità di considerare affidabile una chiave pubblica gestita dal cliente. Il metodo IAM richiede invece di considerare AWS IAM affidabile come emittente.

Il supporto del provider determinerà spesso quale percorso sia praticabile. Alcuni sistemi di identità supportano già Private Key JWT per i client OAuth riservati. Un numero inferiore potrebbe essere configurato per accettare direttamente AWS IAM come emittente.

Private Key JWT occupa quindi un utile punto intermedio. Applica un metodo di autenticazione OAuth standard, mantenendo al contempo il materiale di firma privato sotto il controllo di KMS.

Il significato più ampio della funzionalità risiede nel modo in cui tratta un agente. Invece di fornire all'agente una credenziale riutilizzabile, la piattaforma esegue un'operazione crittografica con autorizzazioni circoscritte quando è necessario l'accesso.

Questo schema riduce il valore dei dati di configurazione copiati. Crea inoltre un punto di controllo applicabile per ogni richiesta di token. Si tratta di miglioramenti concreti per carichi di lavoro autonomi che operano frequentemente e con supervisione limitata.

Il compromesso è una maggiore precisione nella configurazione. I team devono allineare algoritmi, chiavi pubbliche, claim JWT, policy IAM, grant OAuth, scope dei token e controlli di logging.

Amazon AWS ha reso questa complessità più gestibile portando la firma in AgentCore Identity. Non ha però eliminato le decisioni di fiducia che la circondano.

Prima di adottare ampiamente il metodo, scegliete un agente rappresentativo e tracciatene l'intero percorso di accesso. Identificate ogni principal, token, grant, scope, fonte di log e meccanismo di revoca coinvolto.

Quindi testate la rotazione e gli errori, non soltanto l'autenticazione riuscita. Se il vostro team è in grado di spiegare chi ha richiesto ogni firma e cosa è accaduto in seguito, Private Key JWT sta facendo più che sostituire un segreto.