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 con token OAuth 2.0 emette token/oauth2/token
JWTs 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
eAdminInitiateAuth
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 le richiesteAuthFlow
ofREFRESH_TOKEN_AUTH
in o API.InitiateAuth
AdminInitiateAuth
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 al 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
Puoi saperne di più sui client dell'app del pool di utenti e sui relativi tipi di concessione, segreti dei client, ambiti autorizzati 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. Scopes, M2M e APIs con server di risorse
Per recuperare informazioni su un utente dal suo token di accesso, passale al tuo o a un Endpoint UserInfo GetUserRichiesta API.
POST /oauth2/token
L'endpoint /oauth2/token
supporta solo HTTPS POST
. L'app effettua direttamente le richieste a questo endpoint e non tramite il browser.
L'endpoint token supporta l'autenticazione client_secret_basic
e client_secret_post
. Per ulteriori informazioni sulla specifica OpenID Connect, vedere Client
Parametri della richiesta nell'intestazione
Authorization
-
Se il client ha emesso un segreto, dovrà trasmettere i suoi
client_id
eclient_secret
nell'intestazione dell'autorizzazione come autorizzazione HTTPclient_secret_basic
. Puoi inoltre includereclient_id
eclient_secret
nel corpo della richiesta come autorizzazioneclient_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'appdjc98u3jiedmi283eu928
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
grant_type
-
(Obbligatorio) Il tipo di concessione OIDC che desideri richiedere.
Deve essere
authorization_code
orefresh_token
oclient_credentials
. È possibile 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.
-
client_id
-
(Facoltativo) L'ID di un client dell'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) Il segreto del client dell'app che ha autenticato l'utente. Obbligatorio se il client app ha un segreto del client e non è stata inviata una intestazione
Authorization
. scope
-
(Facoltativo) Può essere una combinazione di qualsiasi ambito personalizzato associato a un client di app. Qualsiasi ambito richiesto deve essere attivato per il client dell'app. In caso contrario, Amazon Cognito lo ignorerà. Se il client non richiede alcun ambito, il server di autenticazione assegna tutti gli ambiti personalizzati che hai autorizzato nella configurazione del client dell'app.
Utilizzato solo se il valore
grant_type
èclient_credentials
. redirect_uri
-
(Facoltativo) Deve essere
redirect_uri
lo stesso usato per entrare.authorization_code
/oauth2/authorize
È necessario fornire questo parametro se lo
grant_type
èauthorization_code
. refresh_token
-
(Facoltativo) Per generare nuovi token di accesso e ID per la sessione di un utente, imposta il valore di un
refresh_token
parametro nella/oauth2/token
richiesta su un token di aggiornamento emesso in precedenza dallo stesso client dell'app. code
-
(Facoltativo) Il codice di autorizzazione derivante dalla concessione di un codice di autorizzazione. È necessario fornire questo parametro se la richiesta di autorizzazione includeva un
grant_type
diauthorization_code
. code_verifier
-
(Facoltativo) Il valore arbitrario utilizzato per calcolare il valore contenuto
code_challenge
in una richiesta di concessione del codice di autorizzazione con PKCE.
Richieste di esempio con risposte positive
Sostituzione di un codice di autorizzazione per i token
Esempio: richiesta POST
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
Esempio: risposta
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJra1example",
"id_token": "eyJra2example",
"refresh_token": "eyJj3example",
"token_type": "Bearer",
"expires_in": 3600
}
Nota
L'endpoint del token restituisce refresh_token
solo quando grant_type
è authorization_code
.
Sostituzione delle credenziali del client per un token di accesso: segreto del client nell'intestazione di autorizzazione
Esempio: richiesta POST
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
/scope1
resourceServerIdentifier2
/scope2
Esempio: risposta
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJra1example",
"token_type": "Bearer",
"expires_in": 3600
}
Sostituzione delle credenziali del client per un token di accesso: segreto del client nel corpo della richiesta
Esempio: richiesta POST
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
Esempio: risposta
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"
}
Sostituzione di una concessione del codice di autorizzazione con PKCE per i token
Esempio: richiesta POST
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
Esempio: risposta
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJra1example",
"id_token": "eyJra2example",
"refresh_token": "eyJj3example",
"token_type": "Bearer",
"expires_in": 3600
}
Nota
L'endpoint del token restituisce refresh_token
solo quando grant_type
è authorization_code
.
Sostituzione di un token di aggiornamento per i token
Esempio: richiesta POST
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
Esempio: risposta
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJra1example",
"id_token": "eyJra2example",
"token_type": "Bearer",
"expires_in": 3600
}
Nota
L'endpoint del token restituisce refresh_token
solo quando grant_type
è authorization_code
.
Esempi di risposte negative
Esempio: risposta all'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
marefresh_token
non è incluso. invalid_client
-
L'autenticazione del client non è riuscita. Ad esempio, quando il client include
client_id
eclient_secret
nell'intestazione di autorizzazione, ma non esiste un client con valoriclient_id
eclient_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'attributoemail
, ma nonemail_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 daauthorization_code
,refresh_token
oclient_credentials
.