Point de terminaison de jeton - Amazon Cognito

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.

Point de terminaison de jeton

Le point de terminaison du jeton OAuth 2.0 dans /oauth2/token émet des jetons Web JSON (JWT).

Le serveur d'autorisation OAuth 2.0 de votre groupe d'utilisateurs émet des jetons Web JSON (JWT) depuis le point de terminaison du jeton vers 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.

  2. Sessions M achine-to-machine (M2M) ayant obtenu une autorisation d'identification client. Une autorisation réussie avec le secret du client renvoie un jeton d’accès.

  3. 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 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 à 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 ne sont pas actifs dans votre groupe d'utilisateurs. Si les appareils mémorisés sont actifs, actualisez les jetons avec les requêtes AuthFlow of REFRESH_TOKEN_AUTH in InitiateAuth ou AdminInitiateAuth API.

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

Pour en savoir plus sur les clients de l’application du groupe d’utilisateurs et leurs types de subventions, leurs secrets clients, leurs portées autorisées et leurs ID clients, consultez Clients de l’application de groupe d’utilisateurs. 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. Portées OAuth 2.0 et autorisation d'API avec des 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.

POST /oauth2/jeton

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. Pour plus d’informations sur le point de terminaison de jeton à partir de la norme OpenID Connect, consultez Point de terminaison de jeton.

Paramètres de demande dans l’en-tête

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

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

redirect_uri

(Facultatif) Doit être le même redirect_uri que celui utilisé pour authorization_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 dans 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 code_challenge dans une demande d'octroi de code d'autorisation avec PKCE.

Exemples de demandes avec réponses positives

Échange d’un code d’autorisation contre des jetons

Exemple — requête 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

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 — requête 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

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 — requête 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

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 octroi de code d’autorisation avec PKCE contre des jetons

Exemple — requête 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

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 — requête 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

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