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 ](https://www.rfc-editor.org/rfc/rfc6749#section-3.2) 2.0 `/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 : 1. 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. 1. 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. 1. 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 `InitiateAuth` de l'API `AdminInitiateAuth` peuvent actualiser leurs jetons avec le point de terminaison du jeton lorsque [les appareils mémorisés](amazon-cognito-user-pools-device-tracking.md) *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](amazon-cognito-user-pools-using-the-refresh-token.md#using-the-refresh-token-api) 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](https://datatracker.ietf.org/doc/html/rfc7636) RFC 7636. 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 d'applications](user-pool-settings-client-apps.md)adresse. 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 serveurs de ressources](cognito-user-pools-define-resource-servers.md) Pour récupérer des informations sur un utilisateur à partir de son jeton d'accès, transmettez-les à votre demande [Point de terminaison UserInfo](userinfo-endpoint.md) ou à une demande d'[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)API. 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)](https://openid.net/developers/certified-openid-connect-implementations/) dans votre application. 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](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication). Pour plus d’informations sur le point de terminaison de jeton à partir de la norme OpenID Connect, consultez [Point de terminaison de jeton](http://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint). ### 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_id` et `client_secret` dans l’en-tête d’autorisation en tant qu’autorisation HTTP `client_secret_basic`. Vous pouvez également inclure les `client_id` et `client_secret` dans le corps de la demande en tant qu’autorisation `client_secret_post`. La chaîne d’en-tête d’autorisation est [Basic](https://en.wikipedia.org/wiki/Basic_access_authentication#Client_side) `Base64Encode(client_id:client_secret)`. L'exemple suivant est un en-tête d'autorisation pour le client de l'application `djc98u3jiedmi283eu928` avec le secret client`abcdef01234567890`, 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 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_token` ou `client_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. Le point de terminaison du jeton renvoie un jeton d'actualisation uniquement lorsque `grant_type` c'est le cas`authorization_code`. **`client_id`** *Facultatif. Non obligatoire lorsque vous fournissez l'ID du client de l'application dans l'`Authorization`en-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_post` autorisé. `client_secret` **`client_secret`** *Facultatif. Non obligatoire lorsque vous fournissez le secret du client dans l'`Authorization`en-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_post` l'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 `scope` demande 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-service `aws.cognito.signin.user.admin` utilisateur. **`redirect_uri`** *Facultatif. Non requis pour les autorisations relatives aux informations d'identification des clients.* Doit être le même URI `redirect_uri` que celui utilisé pour obtenir le code `authorization_code` dans `/oauth2/authorize`. Vous devez fournir ce paramètre si tel `grant_type` est le cas`authorization_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_token`actualisation 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](amazon-cognito-user-pools-using-the-refresh-token.md#using-the-refresh-token-rotation) 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](cognito-user-pools-define-resource-servers.md#cognito-user-pools-resource-binding), le nouveau jeton d'accès conserve l'URL d'API demandée dans la `aud` ré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_type` de`authorization_code`. **`aws_client_metadata`** *Facultatif*. Informations que vous souhaitez transmettre aux flux d'autorisation [Déclencheur Lambda avant génération de jeton](user-pool-lambda-pre-token-generation.md) entrants [machine-to-machine (M2M)](cognito-user-pools-define-resource-servers.md). Votre application peut collecter des informations contextuelles sur la session et les transmettre dans ce paramètre. Lorsque vous transmettez `aws_client_metadata` le 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 passe `aws_client_metadata` au 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_method` des `code_challenge` paramètres dans votre demande d'autorisation initiale. Vérificateur de code généré à partir duquel votre application a calculé le code dans le `code_challenge` cadre d'une demande d'octroi de code d'autorisation avec [PKCE](using-pkce-in-authorization-code.md). ## É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'`Authorization`en-tête. ``` 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 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. Comme les informations d'identification du client nécessitent un secret client, la demande est autorisée avec 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 octroyé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=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 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'`Authorization`en-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 octroyé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_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 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](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 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](amazon-cognito-user-pools-using-the-refresh-token.md#using-the-refresh-token-rotation) 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=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw grant_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](amazon-cognito-user-pools-using-the-refresh-token.md#using-the-refresh-token-rotation) 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=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw grant_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_type` est `refresh_token` mais `refresh_token` n’est pas inclus. **`invalid_client`** Échec de l’authentification du client. Par exemple, lorsque le client comprend `client_id` et `client_secret` dans l’en-tête d’autorisation, mais il n’existe pas de client avec ce `client_id` et ce `client_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](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html) dans l’étendue demandée. Par exemple, votre application demande l’étendue `email` et votre client d’application peut lire l’attribut `email`, mais pas `email_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 de `authorization_code`, `refresh_token` ou `client_credentials`.