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 de jetons OAuth /oauth2/token émet des jetons Web JSON (JWTs) aux applications qui souhaitent terminer les flux d'octroi de code d'autorisation et d'informations d'identification client. 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 adressées à ce point de terminaison et répondent aux charges utiles. 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 Web JSON (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 sessions (M2M) qui ont obtenu une autorisation d'identification client. 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 à l'aide d'un code d'autorisation octroyé dans le cadre d'une connexion gérée ou par le biais d'une fédération peuvent toujours actualiser leurs jetons depuis le point de terminaison du jeton. Les utilisateurs qui se connectent à l'aide des opérations
InitiateAuthde l'APIAdminInitiateAuthpeuvent 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 à l'aide de l'API ou de l'opération d'actualisation des jetons du SDK appropriée pour votre client d'application.
Le point de terminaison du jeton devient accessible au public lorsque vous ajoutez un domaine à votre groupe d’utilisateurs. Il accepte les demandes HTTP POST. Pour la sécurité des applications, utilisez PKCE avec les événements de connexion à votre code d'autorisation. PKCE vérifie que l’utilisateur qui transmet un code d’autorisation est le même que celui qui s’est authentifié. Pour plus d'informations sur le PKCE, consultez la norme IETF
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 à l'Paramètres spécifiques à l'application avec les clients de l'applicationadresse. 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-les à votre demande Point de terminaison UserInfo ou à une demande d'GetUserAPI. Le jeton d'accès doit contenir les étendues appropriées pour ces demandes,
Formater une requête POST destinée au point de terminaison du jeton
Le point de terminaison /oauth2/token prend uniquement en charge HTTPS POST. Ce point de terminaison n'est pas interactif avec l'utilisateur. Gérez les demandes de jetons avec une bibliothèque OpenID Connect (OIDC)
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 OIDC, consultez la section Authentification du client
Paramètres de demande dans l’en-tête
Vous pouvez transmettre les paramètres suivants dans l'en-tête de votre demande au point de terminaison du jeton.
Authorization-
Si un secret a été attribué au client, ce dernier doit transmettre les paramètres ses
client_idetclient_secretdans l’en-tête d’autorisation en tant qu’autorisation HTTPclient_secret_basic. Vous pouvez également inclure lesclient_idetclient_secretdans 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'applicationdjc98u3jiedmi283eu928avec le secret clientabcdef01234567890, utilisant la version codée en Base64 de la chaîne :djc98u3jiedmi283eu928:abcdef01234567890Authorization: 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
Les paramètres suivants peuvent être demandés x-www-form-urlencoded au format indiqué dans le corps de la demande au point de terminaison du jeton.
grant_type-
Obligatoire.
Type de subvention OIDC que vous souhaitez demander.
Doit être
authorization_code,refresh_tokenouclient_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.
Note
Le point de terminaison du jeton renvoie un jeton d'actualisation uniquement lorsque
grant_typec'est le casauthorization_code. -
client_id-
Facultatif. Non obligatoire lorsque vous fournissez l'ID du client de l'application dans l'
Authorizationen-tête.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_postautorisé.client_secret client_secret-
Facultatif. Non obligatoire lorsque vous fournissez le secret du client dans l'
Authorizationen-tête et lorsque le client de l'application n'en a pas.Le secret du client de l'application, si le client de l'application en possède un, pour
client_secret_postl'autorisation. scope-
Facultatif.
Il peut s'agir d'une combinaison de toutes les étendues associées à votre client d'application. Amazon Cognito ignore les étendues de la demande qui ne sont pas autorisées pour le client d'application demandé. Si vous ne fournissez pas ce paramètre de demande, le serveur d'autorisation renvoie une
scopedemande de jeton d'accès avec toutes les étendues d'autorisation que vous avez activées dans la configuration de votre client d'application. Vous pouvez demander n'importe quelle étendue autorisée pour le client d'application demandé : étendues standard, étendues personnalisées auprès des serveurs de ressources et étendue en libre-serviceaws.cognito.signin.user.adminutilisateur. redirect_uri-
Facultatif. Non requis pour les autorisations relatives aux informations d'identification des clients.
Doit être le même URI
redirect_urique celui utilisé pour obtenir le codeauthorization_codedans/oauth2/authorize.Vous devez fournir ce paramètre si tel
grant_typeest le casauthorization_code. refresh_token-
Facultatif. Utilisé uniquement lorsque l'utilisateur possède déjà un jeton d'actualisation et souhaite obtenir un nouvel identifiant et des jetons d'accès.
Pour générer de nouveaux jetons d'accès et d'identification pour la session d'un utilisateur, définissez la valeur sur un jeton d'
refresh_tokenactualisation valide émis par le client d'application demandé.Renvoie un nouveau jeton d'actualisation avec un nouvel identifiant et un nouveau jeton d'accès lorsque la rotation des jetons d'actualisation est active, sinon renvoie uniquement les jetons d'identification et d'accès. Si le jeton d'accès d'origine était lié à une ressource d'API, le nouveau jeton d'accès conserve l'URL d'API demandée dans la
audréclamation. code-
Facultatif. Obligatoire uniquement pour les autorisations de code.
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_typedeauthorization_code. aws_client_metadata-
Facultatif.
Informations que vous souhaitez transmettre aux flux d'autorisation Déclencheur Lambda avant génération de jeton entrants machine-to-machine (M2M). Votre application peut collecter des informations contextuelles sur la session et les transmettre dans ce paramètre. Lorsque vous transmettez
aws_client_metadatale format JSON codé par URL, Amazon Cognito l'inclut dans l'événement d'entrée de votre fonction Lambda de déclenchement. La version de votre événement de déclenchement antérieur au jeton ou la version globale de votre déclencheur Lambda doit être configurée pour la version 3 ou ultérieure. Bien qu'Amazon Cognito accepte les demandes adressées à ce point de terminaison dans les flux M2M du code d'autorisation et des informations d'identification du client, votre groupe d'utilisateurs ne passeaws_client_metadataau déclencheur de pré-génération du jeton qu'à partir des demandes d'informations d'identification du client. code_verifier-
Facultatif. Obligatoire uniquement si vous avez fourni
code_challenge_methoddescode_challengeparamètres dans votre demande d'autorisation initiale.Vérificateur de code généré à
code_challengepartir duquel votre application a calculé le code dans une demande d'octroi de code d'autorisation avec PKCE.
Échange d’un code d’autorisation contre des jetons
La demande suivante génère avec succès des jetons d'identification, d'accès et d'actualisation après authentification avec l'octroi d'un code d'autorisation. La demande transmet le secret du client au client_secret_basic format indiqué dans l'Authorizationen-tête.
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token& Content-Type='application/x-www-form-urlencoded'& Authorization=BasicZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkwgrant_type=authorization_code& client_id=1example23456789& code=AUTHORIZATION_CODE& redirect_uri=com.myclientapp://myclient/redirect
La réponse fournit de nouveaux jetons d'identification, d'accès et d'actualisation à l'utilisateur, avec des métadonnées supplémentaires.
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJra1example",
"id_token": "eyJra2example",
"refresh_token": "eyJj3example",
"token_type": "Bearer",
"expires_in": 3600
}
Informations d'identification du client avec autorisation de base
La demande suivante provenant d'une application M2M demande l'octroi d'informations d'identification client. Les informations d'identification du client nécessitant un secret client, la demande est autorisée par un Authorization en-tête dérivé de l'identifiant et du secret du client de l'application. La demande aboutit à un jeton d'accès avec les deux étendues demandées. La demande inclut également les métadonnées du client qui fournissent des informations sur l'adresse IP et un jeton émis à l'utilisateur au nom duquel cette subvention est accordée. Amazon Cognito transmet les métadonnées du client au déclencheur Lambda préalable à la génération du jeton.
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token > Content-Type='application/x-www-form-urlencoded'& Authorization=BasicZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkwgrant_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 transmet l'événement d'entrée suivant au déclencheur Lambda avant la génération du jeton.
{ 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 réponse renvoie un jeton d'accès. Les autorisations d'identification des clients sont destinées à l'autorisation machine-to-machine (M2M) et ne renvoient que des jetons d'accès.
HTTP/1.1 200 OK Content-Type: application/json { "access_token": "eyJra1example", "token_type": "Bearer", "expires_in":3600}
Informations d'identification du client avec autorisation POST
La demande d'autorisation d'identification du client suivante inclut le client_secret paramètre dans le corps de la demande et n'inclut pas d'Authorizationen-tête. Cette demande utilise la syntaxe client_secret_post d'autorisation. La demande aboutit à un jeton d'accès avec l'étendue demandée. La demande inclut également les métadonnées du client qui fournissent des informations sur l'adresse IP et un jeton émis à l'utilisateur au nom duquel cette subvention est accordée. Amazon Cognito transmet les métadonnées du client au déclencheur Lambda préalable à la génération du jeton.
POST /oauth2/token HTTP/1.1 Content-Type: application/x-www-form-urlencoded X-Amz-Target: AWSCognitoIdentityProviderService.Client credentials request User-Agent:USER_AGENTAccept: / Accept-Encoding: gzip, deflate, br Content-Length: 177 Referer: http://auth.example.com/oauth2/token Host:auth.example.comConnection: 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 transmet l'événement d'entrée suivant au déclencheur Lambda avant la génération du jeton.
{ 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 réponse renvoie un jeton d'accès. Les autorisations d'identification des clients sont destinées à l'autorisation machine-to-machine (M2M) et ne renvoient que des jetons d'accès.
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" }
Octroi de code d’autorisation avec PKCE
L'exemple de demande suivant complète une demande d'autorisation qui inclut code_challenge_method des code_challenge paramètres dans une demande d'octroi de code d'autorisation avec PKCE.
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token Content-Type='application/x-www-form-urlencoded'& Authorization=BasicZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkwgrant_type=authorization_code& client_id=1example23456789& code=AUTHORIZATION_CODE& code_verifier=CODE_VERIFIER& redirect_uri=com.myclientapp://myclient/redirect
La réponse renvoie des jetons d'identification, d'accès et d'actualisation issus de la vérification PKCE réussie par l'application.
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJra1example",
"id_token": "eyJra2example",
"refresh_token": "eyJj3example",
"token_type": "Bearer",
"expires_in": 3600
}
Actualisation du jeton sans rotation du jeton d'actualisation
Les exemples de demandes suivants fournissent un jeton d'actualisation à un client d'application où la rotation du jeton d'actualisation est inactive. Comme le client de l'application possède un secret client, la demande fournit un Authorization en-tête.
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token > Content-Type='application/x-www-form-urlencoded'& Authorization=BasicZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkwgrant_type=refresh_token& client_id=1example23456789& refresh_token=eyJj3example
La réponse renvoie un nouvel identifiant et des jetons d'accès.
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJra1example",
"id_token": "eyJra2example",
"token_type": "Bearer",
"expires_in": 3600
}
Actualisation du jeton avec rotation du jeton d'actualisation
Les exemples de demandes suivants fournissent un jeton d'actualisation à un client d'application où la rotation des jetons d'actualisation est active. Comme le client de l'application possède un secret client, la demande fournit un Authorization en-tête.
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token > Content-Type='application/x-www-form-urlencoded'& Authorization=BasicZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkwgrant_type=refresh_token& client_id=1example23456789& refresh_token=eyJj3example
La réponse renvoie de nouveaux jetons d'identification, d'accès et d'actualisation.
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJra1example",
"id_token": "eyJra2example",
"refresh_token": "eyJj4example",
"token_type": "Bearer",
"expires_in": 3600
}
Exemples de réponses négatives
Les demandes mal formées génèrent des erreurs à partir du point de terminaison du jeton. Voici une carte générale du corps de la réponse lorsque les demandes de jetons génèrent 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_typeestrefresh_tokenmaisrefresh_tokenn’est pas inclus. invalid_client-
Échec de l’authentification du client. Par exemple, lorsque le client comprend
client_idetclient_secretdans l’en-tête d’autorisation, mais il n’existe pas de client avec ceclient_idet 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
emailet 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_typeest différent deauthorization_code,refresh_tokenouclient_credentials.