Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # L'endpoint che emette il token L'[endpoint OAuth 2.0 token at `/oauth2/token` emette token](https://www.rfc-editor.org/rfc/rfc6749#section-3.2) web JSON (JWTs) per le applicazioni che desiderano completare i flussi di concessione del codice di autorizzazione e delle credenziali client. Questi token sono il risultato finale dell'autenticazione con un pool di utenti. Contengono informazioni sull'utente (token ID), sul livello di accesso dell'utente (token di accesso) e sul diritto dell'utente a mantenere la sessione di accesso (token di aggiornamento). Le librerie relying-party OpenID Connect (OIDC) gestiscono le richieste e i payload di risposta da questo endpoint. I token forniscono una prova verificabile dell'autenticazione, informazioni sul profilo e un meccanismo per l'accesso ai sistemi di back-end. Il server di autorizzazione del pool di utenti OAuth 2.0 emette token web JSON (JWTs) dall'endpoint del token ai seguenti tipi di sessioni: 1. Utenti che hanno completato una richiesta di concessione del codice di autorizzazione. Il riscatto riuscito di un codice restituisce i token ID, di accesso e di aggiornamento. 1. Machine-to-machine (M2M) sessioni che hanno completato una concessione di credenziali client. L'autorizzazione riuscita con il segreto del client restituisce un token di accesso. 1. Utenti che hanno precedentemente effettuato l'accesso e ricevuto token di aggiornamento. L'autenticazione con token di aggiornamento restituisce nuovi ID e token di accesso. **Nota** Gli utenti che accedono con un codice di autorizzazione concesso nell'accesso gestito o tramite la federazione possono sempre aggiornare i propri token dall'endpoint del token. Gli utenti che accedono con le operazioni API `InitiateAuth` e `AdminInitiateAuth` possono aggiornare i propri token con l'endpoint token quando i [dispositivi ricordati](amazon-cognito-user-pools-device-tracking.md) *non* sono attivi nel pool di utenti. Se i dispositivi ricordati sono attivi, aggiorna i token con l'[API o l'operazione di aggiornamento dei token SDK pertinenti](amazon-cognito-user-pools-using-the-refresh-token.md#using-the-refresh-token-api) per il client dell'app. L'endpoint token diventa disponibile pubblicamente quando si aggiunge un dominio al pool di utenti. Accetta le richieste POST HTTP. Per la sicurezza delle applicazioni, utilizzate PKCE con gli eventi di accesso con il codice di autorizzazione. PKCE verifica che l'utente che trasmette un codice di autorizzazione sia lo stesso utente che ha effettuato l'autenticazione. Per ulteriori informazioni su PKCE, vedere [IETF](https://datatracker.ietf.org/doc/html/rfc7636) RFC 7636. Puoi saperne di più sui client dell'app del pool di utenti e sui relativi tipi di concessione, segreti dei client, ambiti consentiti e client all'indirizzo. IDs [Impostazioni specifiche dell'applicazione con client di app](user-pool-settings-client-apps.md) Puoi saperne di più sull'autorizzazione M2M, sulla concessione delle credenziali dei client e sull'autorizzazione con ambiti dei token di accesso all'indirizzo. [Ambiti, M2M e server di risorse](cognito-user-pools-define-resource-servers.md) Per recuperare informazioni su un utente dal suo token di accesso, passale alla tua richiesta [Endpoint UserInfo](userinfo-endpoint.md) o a una richiesta API. [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUser.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUser.html) Il token di accesso deve contenere gli ambiti appropriati per queste richieste, ## Formatta una richiesta POST sull'endpoint del token L'endpoint `/oauth2/token` supporta solo `HTTPS POST`. Questo endpoint non è interattivo con l'utente. Gestisci le richieste di token con una [libreria OpenID Connect (OIDC) nella tua applicazione](https://openid.net/developers/certified-openid-connect-implementations/). L'endpoint token supporta l'autenticazione `client_secret_basic` e `client_secret_post`. [Per ulteriori informazioni sulla specifica OIDC, vedere Client Authentication.](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication) Per ulteriori informazioni sull'endpoint Token della specifica OpenID Connect, consulta [Endpoint Token](http://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint). ### Parametri della richiesta nell'intestazione È possibile passare i seguenti parametri nell'intestazione della richiesta all'endpoint del token. **`Authorization`** Se il client ha emesso un segreto, dovrà trasmettere i suoi `client_id` e `client_secret` nell'intestazione dell'autorizzazione come autorizzazione HTTP `client_secret_basic`. Puoi inoltre includere `client_id` e `client_secret` nel corpo della richiesta come autorizzazione `client_secret_post`. La stringa di intestazione di autorizzazione è [Base](https://en.wikipedia.org/wiki/Basic_access_authentication#Client_side) `Base64Encode(client_id:client_secret)`. L'esempio seguente è un'intestazione di autorizzazione per il client dell'app `djc98u3jiedmi283eu928` con client secret`abcdef01234567890`, che utilizza la versione della stringa con codifica Base64: `djc98u3jiedmi283eu928:abcdef01234567890` ``` Authorization: Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw ``` **`Content-Type`** Imposta il valore di questo parametro su `'application/x-www-form-urlencoded'`. ### Parametri della richiesta nel corpo Di seguito sono riportati i parametri che è possibile richiedere in `x-www-form-urlencoded` formato nel corpo della richiesta all'endpoint del token. **`grant_type`** *Campo obbligatorio*. Il tipo di concessione OIDC che desideri richiedere. Deve essere `authorization_code` o `refresh_token` o `client_credentials`. Puoi richiedere un token di accesso per un ambito personalizzato dall'endpoint del token alle seguenti condizioni: + Hai abilitato l'ambito richiesto nella configurazione del client dell'app. + Hai configurato il client dell'app con un client secret. + Abilita la concessione delle credenziali del cliente nel client dell'app. L'endpoint del token restituisce un token di aggiornamento solo quando lo è. `grant_type` `authorization_code` **`client_id`** *Facoltativo. Non richiesto quando si fornisce l'ID client dell'app nell'`Authorization`intestazione.* L'ID di un client app nel tuo pool di utenti. Specificate lo stesso client dell'app che ha autenticato l'utente. È necessario fornire questo parametro se il client è pubblico e non dispone di un segreto o è `client_secret_post` autorizzato. `client_secret` **`client_secret`** *Facoltativo. Non richiesto quando si fornisce il segreto del client nell'`Authorization`intestazione e quando il client dell'app non dispone di un segreto.* Il segreto del client dell'app, se il client dell'app ne ha uno, per `client_secret_post` l'autorizzazione. **`scope`** *Facoltativo*. Può essere una combinazione di qualsiasi ambito associato al client dell'app. Amazon Cognito ignora gli ambiti della richiesta che non sono consentiti per il client dell'app richiesto. Se non fornisci questo parametro di richiesta, il server di autorizzazione restituisce una `scope` richiesta di token di accesso con tutti gli ambiti di autorizzazione abilitati nella configurazione del client dell'app. Puoi richiedere uno qualsiasi degli ambiti consentiti per il client dell'app richiesto: ambiti standard, ambiti personalizzati dai server di risorse e ambito self-service dell'`aws.cognito.signin.user.admin`utente. **`redirect_uri`** *Facoltativo. Non richiesto per la concessione delle credenziali del client.* Deve essere lo stesso `redirect_uri` utilizzato per ottenere `authorization_code` in `/oauth2/authorize`. È necessario fornire questo parametro se lo è. `grant_type` `authorization_code` **`refresh_token`** *Facoltativo. Utilizzato solo quando l'utente dispone già di un token di aggiornamento e desidera ottenere un nuovo ID e token di accesso.* Per generare nuovi token di accesso e ID per la sessione di un utente, imposta il valore di su un token `refresh_token` di aggiornamento valido emesso dal client dell'app richiesto. Restituisce un nuovo token di aggiornamento con un nuovo ID e token di accesso quando la [rotazione del token di aggiornamento](amazon-cognito-user-pools-using-the-refresh-token.md#using-the-refresh-token-rotation) è attiva, altrimenti restituisce solo ID e token di accesso. Se il token di accesso originale era [associato a una risorsa API](cognito-user-pools-define-resource-servers.md#cognito-user-pools-resource-binding), il nuovo token di accesso mantiene l'URL dell'API richiesto nel claim. `aud` **`code`** *Facoltativo. Richiesto solo nelle concessioni di codici di autorizzazione.* Il codice di autorizzazione derivante da una concessione di codice di autorizzazione. È necessario fornire questo parametro se la richiesta di autorizzazione includeva un `grant_type` di`authorization_code`. **`aws_client_metadata`** *Facoltativo*. Informazioni che si desidera trasmettere ai flussi di autorizzazione [Trigger Lambda di pre-generazione del token](user-pool-lambda-pre-token-generation.md) in [machine-to-machine (M2M)](cognito-user-pools-define-resource-servers.md). L'applicazione può raccogliere informazioni contestuali sulla sessione e passarle in questo parametro. Quando passi `aws_client_metadata` il formato JSON con codifica URL, Amazon Cognito lo include nell'evento di input della funzione Lambda trigger. La versione dell'evento pre token trigger o la versione globale del trigger Lambda deve essere configurata per la versione tre o successiva. Sebbene Amazon Cognito accetti le richieste a questo endpoint nei flussi M2M del codice di autorizzazione e delle credenziali client, il tuo pool di utenti passa `aws_client_metadata` al trigger precedente alla generazione del token solo dalle richieste di credenziali del client. **`code_verifier`** Opzionale. Richiesto solo se hai fornito i `code_challenge` parametri nella richiesta `code_challenge_method` di autorizzazione iniziale. [Il verificatore di codice generato `code_challenge` da cui l'applicazione ha calcolato in una richiesta di concessione del codice di autorizzazione con PKCE.](using-pkce-in-authorization-code.md) ## Sostituzione di un codice di autorizzazione per i token La seguente richiesta genera correttamente ID, token di accesso e aggiornamento dopo l'autenticazione con una concessione del codice di autorizzazione. La richiesta trasmette il segreto del client nel formato dell'intestazione. `client_secret_basic` `Authorization` ``` POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token& Content-Type='application/x-www-form-urlencoded'& Authorization=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw grant_type=authorization_code& client_id=1example23456789& code=AUTHORIZATION_CODE& redirect_uri=com.myclientapp://myclient/redirect ``` La risposta invia all'utente nuovi ID, token di accesso e aggiornamento, con metadati aggiuntivi. ``` HTTP/1.1 200 OK Content-Type: application/json { "access_token": "eyJra1example", "id_token": "eyJra2example", "refresh_token": "eyJj3example", "token_type": "Bearer", "expires_in": 3600 } ``` ## Credenziali del client con autorizzazione di base La seguente richiesta proveniente da un'applicazione M2M richiede la concessione delle credenziali del client. Poiché le credenziali del client richiedono un client secret, la richiesta viene autorizzata con un'`Authorization`intestazione derivata dall'ID e dal segreto del client dell'app. La richiesta genera un token di accesso con i due ambiti richiesti. La richiesta include anche i metadati del client che forniscono informazioni sull'indirizzo IP e un token rilasciato all'utente per conto del quale questa concessione è concessa. Amazon Cognito passa i metadati del client al trigger Lambda prima della generazione di token. ``` POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token > Content-Type='application/x-www-form-urlencoded'& Authorization=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw grant_type=client_credentials& client_id=1example23456789& scope=resourceServerIdentifier1%2Fscope1%20resourceServerIdentifier2%2Fscope2& &aws_client_metadata=%7B%22onBehalfOfToken%22%3A%22eyJra789ghiEXAMPLE%22,%20%22ClientIpAddress%22%3A%22192.0.2.252%22%7D ``` Amazon Cognito trasmette il seguente evento di input al trigger Lambda prima della generazione del token. ``` { version: '3', triggerSource: 'TokenGeneration_ClientCredentials', region: 'us-east-1', userPoolId: 'us-east-1_EXAMPLE', userName: 'ClientCredentials', callerContext: { awsSdkVersion: 'aws-sdk-unknown-unknown', clientId: '1example23456789' }, request: { userAttributes: {}, groupConfiguration: null, scopes: [ 'resourceServerIdentifier1/scope1', 'resourceServerIdentifier2/scope2' ], clientMetadata: { 'onBehalfOfToken': 'eyJra789ghiEXAMPLE', 'ClientIpAddress': '192.0.2.252' } }, response: { claimsAndScopeOverrideDetails: null } } ``` La risposta restituisce un token di accesso. Le credenziali concesse ai client servono per l'autorizzazione machine-to-machine (M2M) e restituiscono solo token di accesso. ``` HTTP/1.1 200 OK Content-Type: application/json { "access_token": "eyJra1example", "token_type": "Bearer", "expires_in": 3600 } ``` ## Credenziali del cliente con autorizzazione dell'ente POST La seguente richiesta di concessione di credenziali client include il `client_secret` parametro nel corpo della richiesta e non include un'intestazione. `Authorization` Questa richiesta utilizza la sintassi di autorizzazione. `client_secret_post` La richiesta genera un token di accesso con l'ambito richiesto. La richiesta include anche i metadati del client che forniscono informazioni sull'indirizzo IP e un token rilasciato all'utente per conto del quale questa concessione è concessa. Amazon Cognito passa i metadati del client al trigger Lambda prima della generazione di token. ``` POST /oauth2/token HTTP/1.1 Content-Type: application/x-www-form-urlencoded X-Amz-Target: AWSCognitoIdentityProviderService.Client credentials request User-Agent: USER_AGENT Accept: / Accept-Encoding: gzip, deflate, br Content-Length: 177 Referer: http://auth.example.com/oauth2/token Host: auth.example.com Connection: keep-alive grant_type=client_credentials& client_id=1example23456789& scope=my_resource_server_identifier%2Fmy_custom_scope& client_secret=9example87654321& aws_client_metadata=%7B%22onBehalfOfToken%22%3A%22eyJra789ghiEXAMPLE%22,%20%22ClientIpAddress%22%3A%22192.0.2.252%22%7D ``` Amazon Cognito trasmette il seguente evento di input al trigger Lambda prima della generazione del token. ``` { version: '3', triggerSource: 'TokenGeneration_ClientCredentials', region: 'us-east-1', userPoolId: 'us-east-1_EXAMPLE', userName: 'ClientCredentials', callerContext: { awsSdkVersion: 'aws-sdk-unknown-unknown', clientId: '1example23456789' }, request: { userAttributes: {}, groupConfiguration: null, scopes: [ 'resourceServerIdentifier1/my_custom_scope' ], clientMetadata: { 'onBehalfOfToken': 'eyJra789ghiEXAMPLE', 'ClientIpAddress': '192.0.2.252' } }, response: { claimsAndScopeOverrideDetails: null } } ``` La risposta restituisce un token di accesso. Le credenziali concesse ai client servono per l'autorizzazione machine-to-machine (M2M) e restituiscono solo token di accesso. ``` HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Date: Tue, 05 Dec 2023 16:11:11 GMT x-amz-cognito-request-id: 829f4fe2-a1ee-476e-b834-5cd85c03373b { "access_token": "eyJra12345EXAMPLE", "expires_in": 3600, "token_type": "Bearer" } ``` ## Concessione del codice di autorizzazione con PKCE [La seguente richiesta di esempio completa una richiesta di autorizzazione che includeva `code_challenge_method``code_challenge` parametri in una richiesta di concessione del codice di autorizzazione con PKCE.](using-pkce-in-authorization-code.md) ``` POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token Content-Type='application/x-www-form-urlencoded'& Authorization=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw grant_type=authorization_code& client_id=1example23456789& code=AUTHORIZATION_CODE& code_verifier=CODE_VERIFIER& redirect_uri=com.myclientapp://myclient/redirect ``` La risposta restituisce ID, accesso e token di aggiornamento derivanti dall'esito positivo della verifica PKCE da parte dell'applicazione. ``` HTTP/1.1 200 OK Content-Type: application/json { "access_token": "eyJra1example", "id_token": "eyJra2example", "refresh_token": "eyJj3example", "token_type": "Bearer", "expires_in": 3600 } ``` ## Aggiornamento del token senza aggiornamento (rotazione del token) Le seguenti richieste di esempio forniscono un token di aggiornamento a un client di app in cui la [rotazione del token di aggiornamento](amazon-cognito-user-pools-using-the-refresh-token.md#using-the-refresh-token-rotation) è inattiva. Poiché il client dell'app dispone di un client secret, la richiesta fornisce un'intestazione. `Authorization` ``` POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token > Content-Type='application/x-www-form-urlencoded'& Authorization=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw grant_type=refresh_token& client_id=1example23456789& refresh_token=eyJj3example ``` La risposta restituisce nuovi ID e token di accesso. ``` HTTP/1.1 200 OK Content-Type: application/json { "access_token": "eyJra1example", "id_token": "eyJra2example", "token_type": "Bearer", "expires_in": 3600 } ``` ## Aggiornamento dei token con rotazione dei token di aggiornamento Le seguenti richieste di esempio forniscono un token di aggiornamento a un client di app in cui è attiva la [rotazione del token di aggiornamento](amazon-cognito-user-pools-using-the-refresh-token.md#using-the-refresh-token-rotation). Poiché il client dell'app dispone di un client secret, la richiesta fornisce un'`Authorization`intestazione. ``` POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token > Content-Type='application/x-www-form-urlencoded'& Authorization=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw grant_type=refresh_token& client_id=1example23456789& refresh_token=eyJj3example ``` La risposta restituisce nuovi ID, token di accesso e aggiornamento. ``` HTTP/1.1 200 OK Content-Type: application/json { "access_token": "eyJra1example", "id_token": "eyJra2example", "refresh_token": "eyJj4example", "token_type": "Bearer", "expires_in": 3600 } ``` ## Esempi di risposte negative Le richieste non valide generano errori dall'endpoint del token. Di seguito è riportata una mappa generale del corpo della risposta quando le richieste di token generano un errore. ``` HTTP/1.1 400 Bad Request Content-Type: application/json;charset=UTF-8 { "error":"invalid_request|invalid_client|invalid_grant|unauthorized_client|unsupported_grant_type" } ``` **`invalid_request`** Nella richiesta manca un parametro obbligatorio, include un valore di parametro non supportato (diverso da `unsupported_grant_type`) oppure è comunque non corretto. Ad esempio, `grant_type` è `refresh_token` ma `refresh_token` non è incluso. **`invalid_client`** L'autenticazione del client non è riuscita. Ad esempio, quando il client include `client_id` e `client_secret` nell'intestazione di autorizzazione, ma non esiste un client con valori `client_id` e `client_secret`. **`invalid_grant`** Il token di aggiornamento è stato revocato. Il codice di autorizzazione è stato utilizzato già o non esiste. Il client dell'app non ha accesso in lettura a tutti gli [attributi](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html) nell'ambito richiesto. Ad esempio, l'app richiede l'ambito `email` e il client dell'app può leggere l'attributo `email`, ma non `email_verified`. **`unauthorized_client`** Il client non ha le autorizzazioni necessarie per il flusso di concessione del codice o per l'aggiornamento dei token. **`unsupported_grant_type`** Restituito se `grant_type` è diverso da `authorization_code`, `refresh_token` o `client_credentials`.