Riferimento autenticazione authentication-reference
Utilizzare questa pagina per cercare campi e contratti di autenticazione. Per le istruzioni di installazione, vedere Autenticare gli utenti finali con il proprio provider di identità.
Impostazioni di autenticazione authentication-settings
Apri Impostazioni > Autenticazione. Ogni ambiente memorizza le proprie impostazioni. Utilizza il selettore Workspace per selezionare l’ambiente da modificare; il salvataggio delle impostazioni non influisce mai sull’altro ambiente.
iss prevista. Deve essere HTTPS. Pubblicato anche come server di autorizzazione dell’app. Un provider di identità per appRegole di convalida
offline_access è elencato in Ambiti supportati o in un’azioneoffline_access richiede un token di aggiornamento dal server di autorizzazione anziché concedere l’accesso all’app, pertanto non è un ambito pubblicizzato dall’app. Non è necessario elencarla: la piattaforma LLM lo richiede direttamente al server di autorizzazioneLe barre finali dell’emittente sono normalizzate. Il confronto di iss tollera la differenza, pertanto i token di un provider che include sempre una barra finale vengono comunque convalidati.
Modalità di autenticazione auth-modes
Impostato per azione in Configurazione per azione.
noauthoauth2noauth e oauth2Il gestore di un’azione Required non viene mai eseguito senza un token con ambito corretto valido. Il gestore di un’azione Optional è sempre in esecuzione e può richiedere l’accesso con extra.challengeAuth().
Obbligatorio è pertanto l’unica modalità che rifiuta i chiamanti non autenticati. Un’app rifiuta tutte le chiamate anonime solo quando ogni azione è obbligatoria. Se un’azione è None o Optional, l’app utilizza l’autenticazione mista perché almeno un’azione accetta chiamate anonime.
Le modalità di autenticazione hanno effetto solo quando Abilita autenticazione è attivo. Le modifiche hanno effetto sulla prossima distribuzione dell’app.
La modifica dello switch di autenticazione riscrive anche le modalità per azione:
Il passaggio a Workspace non riscrive mai le modalità. Il selettore carica la configurazione salvata dell’altro ambiente senza modificarla.
Con Abilita autenticazione in e ogni azione impostata su Nessuna, l’app non richiede l’autenticazione ma pubblica comunque il server di autorizzazione per l’individuazione. Per rendere l’app completamente pubblica, disattiva lo switch.
Un’app può utilizzare diverse modalità di autenticazione per le singole azioni. Per informazioni sulle modalità di applicazione di ciascuna piattaforma, vedere comportamento della piattaforma LLM.
Requisiti del token token-requirements
Il provider di identità deve rilasciare token di accesso che soddisfino tutti i seguenti requisiti. Il runtime considera assente un token che non supera un controllo: il chiamante non è autenticato e un’azione Obbligatorio impedisce al chiamante di accedere.
RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384 o PS512. Gli algoritmi HMAC come HS256 vengono rifiutatiissaudexpscope oppure scpscope delimitata da spazi o utilizza come fallback una matrice di stringhe in scp. Utilizzare una di queste forme per controllare gli ambiti in base ai requisiti di ogni azionesubgetAuthenticatedUserAuthorization: Bearer <token> intestazione di richiestaEventuali attestazioni flat aggiuntive incluse dal provider, ad esempio tenant o email, vengono passate al gestore. Gli oggetti nidificati vengono eliminati e i valori stringa lunghi vengono troncati.
Individuazione provider di identità discovery
L’app pubblica i metadati delle risorse protette RFC 9728 in modo che le piattaforme LLM possano individuare il server di autorizzazione. Non è necessario creare, ospitare o configurare i metadati delle risorse protette.
Il provider di identità deve fornire le seguenti informazioni di individuazione:
jwks_uri, ma non torna al percorso di individuazione OIDChttps://auth.example.com/oauth2/default fornisce i propri metadati in https://auth.example.com/.well-known/oauth-authorization-server/oauth2/defaultAPI di autenticazione gestore handler-auth-api
Il pacchetto @adobe/llm-apps-runtime esporta i seguenti helper. Ogni helper accetta extra, il secondo argomento ricevuto dal gestore.
getAuthenticatedUser(extra)sub dell’utente connesso o undefined quando la chiamata non è autenticatahasScope(extra, scope)true quando il token del chiamante contiene scopeLe informazioni sul token verificato sono disponibili in extra.authInfo, che è undefined per una chiamata non autenticata.
authInfo.tokenauthInfo.clientIdclient_id o azp oppure unknownauthInfo.scopesauthInfo.expiresAtexpauthInfo.resourceauthInfo.extrasub più altre richieste di rimborso forfettarie incluse nel provider di identitàextra.challengeAuth(options) è disponibile solo per Azioni facoltative. Restituisce il risultato dal gestore per chiedere all’utente di accedere invece di restituire il contenuto.
L’helper restituisce un risultato di strumento per ChatGPT. Claude richiede una richiesta HTTP a livello di trasporto. Il runtime fornisce tale verifica per le azioni Obbligatorie, ma non tramite l’helper del gestore facoltativo.
errorinvalid_token, insufficient_scope o invalid_request. Impostazione predefinita: insufficient_scopeerrorDescriptionscopeerror esplicitamente. Utilizzare invalid_token per un chiamante senza una sessione valida e insufficient_scope solo per un chiamante il cui token è valido ma non dispone di un ambito richiesto. Il runtime passa il valore alla piattaforma LLM, che sceglie la formulazione del prompt di accesso. Invia il codice che descrive accuratamente la condizione anziché il codice con la richiesta preferita.Comportamento della piattaforma LLM platform-behavior
Entrambe le piattaforme supportano azioni pubbliche e protette nella stessa app, ma i trigger di accesso sono diversi.
extra.challengeAuth() del gestore facoltativoPer informazioni sul comportamento corrente del client, vedere Claude lazy authentication e ChatGPT authentication. L’interfaccia utente e i criteri del connettore possono variare a seconda dell’account e dell’organizzazione.