Formato della richiesta Esempio: codice di autorizzazione Esempio: credenziali client con autorizzazione di base Esempio: credenziali client con autorizzazione del corpo Esempio: codice di autorizzazione con PKCE Esempio: concessione del token di aggiornamento senza rotazione Esempio: aggiornamento della rotazione dei token Risposte agli errori

L'endpoint che emette il token

L'endpoint OAuth 2.0 token at /oauth2/token emette token 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:

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.
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.
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 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 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 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 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

Per recuperare informazioni su un utente dal suo token di accesso, passale alla tua richiesta Endpoint UserInfo o a una richiesta API. GetUser 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.

L'endpoint token supporta l'autenticazione client_secret_basic e client_secret_post. Per ulteriori informazioni sulla specifica OIDC, consulta Client Authentication. Per ulteriori informazioni sull'endpoint Token della specifica OpenID Connect, consulta Endpoint Token.

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 Base64Encode(client_id:client_secret). L'esempio seguente è un'intestazione di autorizzazione per il client dell'app djc98u3jiedmi283eu928 con client secretabcdef01234567890, 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.

Nota

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'Authorizationintestazione.

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'Authorizationintestazione 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.adminutente.

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 è attiva, altrimenti restituisce solo ID e token di accesso. Se il token di accesso originale era associato a una risorsa API, 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 diauthorization_code.

aws_client_metadata

Facoltativo.

Informazioni che si desidera trasmettere ai flussi di autorizzazione Trigger Lambda di pre-generazione del token in machine-to-machine (M2M). 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.

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'Authorizationintestazione 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_methodcode_challenge parametri in una richiesta di concessione del codice di autorizzazione con PKCE.


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 è 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. Poiché il client dell'app dispone di un client secret, la richiesta fornisce un'Authorizationintestazione.


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 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.

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Endpoint Authorize

Endpoint UserInfo