Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Le point de terminaison de l'émetteur du jeton
Le point de terminaison du jeton OAuth/oauth2/token
émet des jetons JSON Web (JWTs). Ces jetons sont le résultat final de l'authentification auprès d'un groupe d'utilisateurs. Ils contiennent des informations sur l'utilisateur (jeton d'identification), le niveau d'accès de l'utilisateur (jeton d'accès) et le droit de l'utilisateur à conserver sa session de connexion (jeton d'actualisation). Les bibliothèques dépendantes d'OpenID Connect (OIDC) gèrent les demandes et répondent aux charges utiles depuis ce point de terminaison. Les jetons fournissent une preuve d'authentification vérifiable, des informations de profil et un mécanisme d'accès aux systèmes principaux.
Le serveur d'autorisation de votre groupe d'utilisateurs OAuth 2.0 émet des jetons JSON Web (JWTs) depuis le point de terminaison du jeton pour les types de sessions suivants :
-
Utilisateurs ayant effectué une demande d'octroi de code d'autorisation. L’utilisation réussie d’un code retourne les jetons d’ID, d’accès et d’actualisation.
-
Machine-to-machine (M2M) pour lesquelles une autorisation d'identification client a été octroyée. Une autorisation réussie avec le secret du client renvoie un jeton d’accès.
-
Utilisateurs qui se sont déjà connectés et ont reçu des jetons d'actualisation. L'authentification par jeton d'actualisation renvoie un nouvel identifiant et des jetons d'accès.
Note
Les utilisateurs qui se connectent avec un code d'autorisation octroyé dans l'interface utilisateur hébergée ou via la fédération peuvent toujours actualiser leurs jetons depuis le point de terminaison du jeton. Les utilisateurs qui se connectent via les API opérations
InitiateAuth
etAdminInitiateAuth
peuvent actualiser leurs jetons avec le point de terminaison du jeton lorsque les appareils mémorisés ne sont pas actifs dans votre groupe d'utilisateurs. Si les appareils mémorisés sont actifs, actualisez les jetons avec lesAdminInitiateAuth
API requêtesAuthFlow
ofREFRESH_TOKEN_AUTH
inInitiateAuth
ou.
Le point de terminaison du jeton devient accessible au public lorsque vous ajoutez un domaine à votre groupe d’utilisateurs. Il accepte les HTTP POST demandes. Pour la sécurité des applications, utilisez PKCE les événements de connexion avec votre code d'autorisation. PKCEvérifie que l'utilisateur qui transmet un code d'autorisation est le même que celui qui s'est authentifié. Pour plus d'informations surPKCE, voir IETFRFC7636
Vous pouvez en savoir plus sur les clients de l'application du pool d'utilisateurs et leurs types de subventions, leurs secrets clients, leurs étendues autorisées et leurs clients IDs surParamètres spécifiques à l'application avec les clients d'applications. Vous pouvez en savoir plus sur l'autorisation M2M, les autorisations d'identification des clients et les étendues d'autorisation avec jetons d'accès à l'adresse. Éscopes, M2M et APIs avec serveurs de ressources
Pour récupérer des informations sur un utilisateur à partir de son jeton d'accès, transmettez-le à votre userInfo point final ou à un GetUserAPIdemande.
POST /oauth2/token
Le point de terminaison /oauth2/token
prend uniquement en charge HTTPS POST
. Votre application envoie des requêtes à ce point de terminaison directement, sans passer par le navigateur de l’utilisateur.
Le point de terminaison du jeton prend en charge client_secret_basic
et l’authentification client_secret_post
. Pour plus d'informations sur la spécification OpenID Connect, consultez la section Authentification du client
Paramètres de demande dans l’en-tête
Authorization
-
Si un secret a été délivré au client, il peut transmettre son
client_id
etclient_secret
dans l'en-tête d'autorisation en tant qu'client_secret_basic
HTTPautorisation. Vous pouvez également inclure lesclient_id
etclient_secret
dans le corps de la demande en tant qu’autorisationclient_secret_post
.La chaîne d’en-tête d’autorisation est Basic
Base64Encode(client_id:client_secret)
. L'exemple suivant est un en-tête d'autorisation pour le client de l'applicationdjc98u3jiedmi283eu928
avec le secret clientabcdef01234567890
, utilisant la version codée en Base64 de la chaîne :djc98u3jiedmi283eu928:abcdef01234567890
Authorization: Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw
Content-Type
-
Définissez la valeur de ce paramètre sur
'application/x-www-form-urlencoded'
.
Paramètres de la demande dans le corps
grant_type
-
(Obligatoire) Type de OIDC subvention que vous souhaitez demander.
Doit être
authorization_code
,refresh_token
ouclient_credentials
. Vous pouvez demander un jeton d'accès pour une étendue personnalisée auprès du point de terminaison du jeton dans les conditions suivantes :-
Vous avez activé l'étendue demandée dans la configuration du client de votre application.
-
Vous avez configuré votre client d'application avec un secret client.
-
Vous activez l'octroi d'informations d'identification client dans le client de votre application.
-
client_id
-
(Facultatif) L'ID d'un client d'application dans votre groupe d'utilisateurs. Spécifiez le même client d'application qui a authentifié votre utilisateur.
Vous devez fournir ce paramètre si le client est public et n'a pas de secret, ou s'il n'est pas
client_secret_post
autorisé.client_secret
client_secret
-
(Facultatif) Le secret du client de l'application qui a authentifié votre utilisateur. Obligatoire si votre client d’application dispose d’un secret client et vous n’avez pas envoyé un en-tête
Authorization
. scope
-
(Facultatif) Il peut s'agir d'une combinaison de toutes les étendues personnalisées associées à un client d'application. Toute étendue que vous demandez doit être activée pour le client de l'application. Dans le cas contraire, Amazon Cognito l'ignorera. Si le client ne demande aucune étendue, le serveur d'authentification attribue toutes les étendues personnalisées que vous avez autorisées dans la configuration de votre client d'application.
Utilisé uniquement si le
grant_type
estclient_credentials
. redirect_uri
-
(Facultatif) Doit être le même
redirect_uri
que celui utilisé pourauthorization_code
entrer/oauth2/authorize
.Vous devez fournir ce paramètre si tel
grant_type
est le casauthorization_code
. refresh_token
-
(Facultatif) Pour générer de nouveaux jetons d'accès et d'identification pour la session d'un utilisateur, définissez la valeur d'un
refresh_token
paramètre de votre/oauth2/token
demande sur un jeton d'actualisation précédemment émis par le même client d'application. code
-
(Facultatif) Le code d'autorisation issu de l'octroi d'un code d'autorisation. Vous devez fournir ce paramètre si votre demande d'autorisation inclut un
grant_type
deauthorization_code
. code_verifier
-
(Facultatif) La valeur arbitraire que vous avez utilisée pour calculer la valeur
code_challenge
dans une demande d'octroi de code d'autorisationPKCE.
Exemples de demandes avec réponses positives
Échange d’un code d’autorisation contre des jetons
Exemple — POST demande
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
Exemple — réponse
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJra1example",
"id_token": "eyJra2example",
"refresh_token": "eyJj3example",
"token_type": "Bearer",
"expires_in": 3600
}
Note
Le point de terminaison de jeton renvoie refresh_token
uniquement lorsque la valeur de grant_type
est authorization_code
.
Échange d’informations d’identification de client contre un jeton d’accès : secret de client dans l’en-tête d’autorisation
Exemple — POST demande
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
Exemple — réponse
HTTP/1.1 200 OK Content-Type: application/json { "access_token": "eyJra1example", "token_type": "Bearer", "expires_in": 3600 }
Échange d’informations d’identification de client contre un jeton d’accès : secret de client dans le corps de la demande
Exemple — POST demande
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
Exemple — réponse
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" }
Échange d'un code d'autorisation octroyé avec PKCE des jetons
Exemple — POST demande
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
Exemple — réponse
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJra1example",
"id_token": "eyJra2example",
"refresh_token": "eyJj3example",
"token_type": "Bearer",
"expires_in": 3600
}
Note
Le point de terminaison de jeton renvoie refresh_token
uniquement lorsque la valeur de grant_type
est authorization_code
.
Échange d’un jeton d’actualisation contre des jetons
Exemple — POST demande
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
Exemple — réponse
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJra1example",
"id_token": "eyJra2example",
"token_type": "Bearer",
"expires_in": 3600
}
Note
Le point de terminaison de jeton renvoie refresh_token
uniquement lorsque la valeur de grant_type
est authorization_code
.
Exemples de réponses négatives
Exemple — réponse à une erreur
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
-
Un paramètre obligatoire n’est pas inclus dans la demande, la demande comprend une valeur de paramètre non pris en charge (autre que
unsupported_grant_type
) ou la demande présente un autre défaut. Par exemple,grant_type
estrefresh_token
maisrefresh_token
n’est pas inclus. invalid_client
-
Échec de l’authentification du client. Par exemple, lorsque le client comprend
client_id
etclient_secret
dans l’en-tête d’autorisation, mais il n’existe pas de client avec ceclient_id
et ceclient_secret
. invalid_grant
-
Le jeton d’actualisation a été révoqué.
Le code d’autorisation a déjà été utilisé ou n’existe pas.
Le client d’application n’a pas accès en lecture à tous les attributs dans l’étendue demandée. Par exemple, votre application demande l’étendue
email
et votre client d’application peut lire l’attributemail
, mais pasemail_verified
. unauthorized_client
-
Le client n’a pas d’autorisation pour le flux d’octroi de code ou pour les jetons d’actualisation.
unsupported_grant_type
-
Renvoyé si
grant_type
est différent deauthorization_code
,refresh_token
ouclient_credentials
.