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 l'émetteur du jeton

Le point de terminaison du jeton OAuth 2.0 /oauth2/token émet des jetons Web JSON (JWT) aux applications qui souhaitent compléter les flux d'octroi de codes 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), son niveau d'accès (jeton d'accès) et son droit à poursuivre sa session de connexion (jeton d'actualisation). Les bibliothèques dépendantes d'OpenID Connect (OIDC) gèrent les requêtes et répondent aux charges utiles depuis ce point de terminaison. Les jetons fournissent une preuve vérifiable d'authentification, des informations de profil et un mécanisme d'accès aux systèmes principaux.

Le point de terminaison du jeton renvoie un en-tête de Access-Control-Allow-Origin: * réponse. Vous pouvez appeler le point de terminaison du jeton cross-origin à partir d'une application basée sur un navigateur. Par exemple, vous pouvez accorder un code d'autorisation à l'aide de la clé de preuve pour l'échange de code (PKCE) depuis un client public. Amazon Cognito ne prend pas en charge les politiques d'origine CORS (cross-origin resource sharing) personnalisées sur ce point de terminaison. Pour plus d'informations, consultez la section sur les politiques CORS deConnexion gérée par le groupe d'utilisateurs.

Le serveur d'autorisation OAuth 2.0 de votre groupe d'utilisateurs émet des jetons Web JSON (JWT) depuis le point de terminaison des jetons vers les types de sessions suivants :

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 vos événements de connexion par 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 PKCE, consultez la RFC 7636 de l'IETF.

Vous pouvez en savoir plus sur les clients des applications du pool d'utilisateurs et leurs types d'autorisations, les secrets clients, les étendues autorisées et les identifiants clients surParamètres spécifiques à l'application avec les clients d'applications. Vous pouvez en savoir plus sur l'autorisation M2M, l'attribution des informations d'identification des clients et l'autorisation avec des étendues de jetons d'accès sur. Scopes, M2M et 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 vers le 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 pour l'utilisateur. Gérez les demandes de jetons à l'aide d'une bibliothèque OpenID Connect (OIDC) intégrée à 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. 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

Vous pouvez transmettre les paramètres suivants dans l'en-tête de votre demande au point de terminaison du jeton.

Paramètres de la demande dans le corps

Les paramètres suivants peuvent être demandés x-www-form-urlencoded au format dans le corps de la demande au point de terminaison du jeton.

É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 à l'aide d'un code d'autorisation. La demande transmet le secret client client_secret_basic au 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=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw

grant_type=authorization_code&
client_id=1example23456789&
code=AUTHORIZATION_CODE&
redirect_uri=com.myclientapp://myclient/redirect

La réponse fournit un nouvel identifiant, des jetons d'accès et d'actualisation à l'utilisateur, ainsi que 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 émanant d'une application M2M demande l'octroi d'informations d'identification au client. Étant donné que 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'ID et du secret du client de l'application. La demande génère un jeton d'accès avec les deux étendues demandées. La demande inclut également des métadonnées du client qui fournissent des IP-address informations et un jeton émis à l'utilisateur pour le compte duquel cette autorisation est accordée. Amazon Cognito transmet les métadonnées du client au déclencheur Lambda de pré-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 préalable à 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 informations d'identification des clients sont accordées pour l'autorisation de machine à 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'octroi d'informations d'identification 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 génère un jeton d'accès avec la portée demandée. La demande inclut également des métadonnées du client qui fournissent des IP-address informations et un jeton émis à l'utilisateur pour le compte duquel cette autorisation est accordée. Amazon Cognito transmet les métadonnées du client au déclencheur Lambda de pré-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 préalable à 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 informations d'identification des clients sont accordées pour l'autorisation de machine à 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 incluait code_challenge_method et code_challenge paramétrait 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=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 les 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 actualisation de la rotation du jeton

Les exemples de demandes suivants fournissent un jeton d'actualisation à un client d'application où la rotation du jeton d'actualisation est inactive. Étant donné que 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 de nouveaux 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 des jetons avec actualisation de la rotation des jetons

Les exemples de demandes suivants fournissent un jeton d'actualisation à un client d'application où la rotation du jeton d'actualisation est active. Étant donné que 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, des jetons 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 depuis le 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"
}