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.
# Points de terminaison du fournisseur d'identité et des parties utilisatrices
Les *points de terminaison de fédération* sont des points de terminaison de groupes d'utilisateurs répondant à l'une des normes d'authentification utilisées par les groupes d'utilisateurs. Ils incluent le SAML ACS URLs, les points de terminaison de découverte OIDC et les points de terminaison de service pour les rôles du pool d'utilisateurs à la fois en tant que fournisseur d'identité et partie utilisatrice. Les points de terminaison de la fédération initient des flux d'authentification, reçoivent des preuves d' IdPsauthentification et émettent des jetons aux clients. Ils interagissent avec IdPs les applications et les administrateurs, mais pas avec les utilisateurs.
Les rubriques complètes qui suivent cette page contiennent des détails sur les points de terminaison des fournisseurs OAuth 2.0 et OIDC qui deviennent disponibles lorsque vous ajoutez un domaine à votre groupe d'utilisateurs. Le tableau suivant est une liste de tous les points de terminaison de la fédération.
Voici des exemples de [domaines de pool d'utilisateurs](cognito-user-pools-assign-domain.md) :
1. Domaine de préfixe : `mydomain.auth.us-east-1.amazoncognito.com`
1. Domaine personnalisé : `auth.example.com`
**Points de terminaison de fédération de groupes d’utilisateurs**
| URL de point de terminaison | Description | Procédure d’accès |
| --- | --- | --- |
| https ://Your user pool domain/oauth2/authorize | Redirige un utilisateur vers une connexion gérée ou vers une connexion avec son IdP. | Invoqué dans le navigateur du client pour démarrer l'authentification de l'utilisateur. Consultez [Point de terminaison d’autorisation](authorization-endpoint.md). |
| https ://Your user pool domain/oauth2/token | Renvoie des jetons en fonction d’un code d’autorisation ou d’une demande d’informations d’identification client. | Demandé par l'application pour récupérer des jetons. Consultez [Point de terminaison de jeton](token-endpoint.md). |
| https ://Your user pool domain/OAuth2/UserInfo | Renvoie les attributs utilisateur basés sur les étendues OAuth 2.0 et l'identité de l'utilisateur dans un jeton d'accès. | Demandé par l'application pour récupérer le profil de l'utilisateur. Consultez [Point de terminaison UserInfo](userinfo-endpoint.md). |
| https ://Your user pool domain/oauth2/revoke | Révoque un jeton d’actualisation et les jetons d’accès associés. | Demandé par l'application pour révoquer un jeton. Consultez [Point de terminaison de révocation](revocation-endpoint.md). |
| https://cognito-idp. Region.amazonaws.com/ /.well-known/openid-configuration your user pool ID | Un répertoire de l'architecture OIDC de votre groupe d'utilisateurs. [1](#cognito-federation-oidc-discovery-note) | Demandé par l'application pour localiser les métadonnées de l'émetteur du pool d'utilisateurs. |
| https://cognito-idp. Region.amazonaws.com/ /.well-known/jwks.json your user pool ID | Clés publiques que vous pouvez utiliser pour valider les jetons Amazon Cognito. [2](#cognito-federation-oidc-jwks-note) | Demandé par l'application pour vérifier JWTs. |
| https ://Your user pool domain/oauth2/idpresponse | Les fournisseurs d’identité sociale doivent rediriger vos utilisateurs vers ce point de terminaison à l’aide d’un code d’autorisation. Amazon Cognito échange le code contre un jeton lorsqu’il authentifie votre utilisateur fédéré. | Redirigé depuis la connexion au fournisseur d’identité OIDC en tant qu’URL de rappel du client du fournisseur d’identité. |
| Your user pool domainhttps://saml2/idpresponse | URL d'Assertion Consumer Response (ACS) pour l'intégration avec les fournisseurs d'identité SAML 2.0. | Redirigé depuis SAML 2.0 IdP en tant qu'URL ACS ou point d'origine pour la connexion initiée par l'IdP. [3](#cognito-federation-idp-init-note) |
| https ://Your user pool domain/saml2/logout | URL de [déconnexion unique](cognito-user-pools-saml-idp-sign-out.md#cognito-user-pools-saml-idp-sign-out.title) (SLO) pour l'intégration avec les fournisseurs d'identité SAML 2.0. | Redirigé depuis SAML 2.0 IdP en tant qu'URL de déconnexion unique (SLO). Accepte uniquement la reliure POST. |
1 Le `openid-configuration` document peut être mis à jour à tout moment avec des informations supplémentaires permettant de maintenir le terminal conforme à l'OIDC et aux OAuth2 spécifications.
2 Le fichier `jwks.json` JSON peut être mis à jour à tout moment avec de nouvelles clés de signature à jeton public.
3 Pour plus d'informations sur la connexion SAML initiée par l'IdP, consultez. [Mettre en œuvre la connexion SAML initiée par l'IdP](cognito-user-pools-SAML-session-initiation.md#cognito-user-pools-SAML-session-initiation-idp-initiation)
[Pour plus d'informations sur OpenID Connect et les OAuth standards, consultez OpenID [Connect](http://openid.net/specs/openid-connect-core-1_0.html) 1.0 et 2.0. OAuth](https://tools.ietf.org/html/rfc6749)
**Topics**
+ [Le point de terminaison de redirection et d'autorisation](authorization-endpoint.md)
+ [Le point de terminaison de l'émetteur du jeton](token-endpoint.md)
+ [Le point de terminaison des attributs utilisateur](userinfo-endpoint.md)
+ [Le point de terminaison de révocation des jetons](revocation-endpoint.md)
+ [Le point de terminaison d'assertion IDP SAML](saml2-idpresponse-endpoint.md)
# Le point de terminaison de redirection et d'autorisation
Le point de terminaison `/oauth2/authorize` est un point de terminaison de redirection qui prend en charge deux destinations de redirection Si vous incluez un paramètre `identity_provider` ou `idp_identifier` dans l’URL, il redirige en mode silencieux votre utilisateur vers la page de connexion de ce fournisseur d’identité (IdP). Sinon, il redirige vers le [Point de terminaison de connexion](login-endpoint.md) avec les mêmes paramètres d’URL que ceux que vous avez inclus dans votre demande.
Le point de terminaison autorisé redirige soit vers une connexion gérée, soit vers une page de connexion IdP. La destination d’une session utilisateur sur ce point de terminaison est une page Web avec laquelle votre utilisateur doit interagir directement dans son navigateur.
Pour utiliser le point de terminaison d’autorisation, appelez le navigateur de votre utilisateur à l’adresse `/oauth2/authorize` avec des paramètres qui fournissent à votre groupe d’utilisateurs des informations sur les détails suivants du groupe d’utilisateurs.
+ Client d’application auquel vous souhaitez vous connecter.
+ URL de rappel à laquelle vous souhaitez accéder.
+ Les étendues OAuth 2.0 que vous souhaitez demander dans le jeton d'accès de votre utilisateur.
+ IdP tiers (facultatif) que vous souhaitez utiliser pour vous connecter.
Vous pouvez également fournir les paramètres `state` et `nonce` utilisés par Amazon Cognito pour valider les demandes entrantes.
## GET `/oauth2/authorize`
Le point de terminaison `/oauth2/authorize` prend uniquement en charge `HTTPS GET`. Votre application lance généralement cette demande dans le navigateur de votre utilisateur. Vous pouvez adresser vos demandes au point de terminaison `/oauth2/authorize` uniquement via HTTPS.
Pour en savoir plus sur la définition du point de terminaison d’autorisation dans la norme OpenID Connect (OIDC), veuillez consulter [Authorization Endpoint](http://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthorizationEndpoint) (français non disponible).
### Paramètres de demande
**`response_type`**
Obligatoire.
Type de réponse. Doit être `code` ou `token`.
Une demande réussie avec un `response_type` égal à `code` renvoie un octroi de code d’autorisation. L’octroi de code d’autorisation est un paramètre `code` ajouté par Amazon Cognito à votre URL de redirection. Votre application peut échanger ce code avec le [Point de terminaison de jeton](token-endpoint.md) pour obtenir les jetons d’accès, d’identification et d’actualisation. À titre de bonne pratique en matière de sécurité et pour recevoir des jetons d’actualisation pour vos utilisateurs, utilisez un octroi de code d’autorisation dans votre application.
Une demande réussie avec un `response_type` égal à `token` renvoie un octroi implicite. Un octroi implicite est un jeton d’identifiant et d’accès ajouté par Amazon Cognito à votre URL de redirection. Un octroi implicite est moins sûr car il expose les jetons et les informations d’identification potentielles aux utilisateurs. Vous pouvez désactiver la prise en charge des octrois implicites dans la configuration de votre client d’application.
**`client_id`**
Obligatoire.
ID du client d'application.
La valeur de `client_id` doit être l’ID d’un client d’application du groupe d’utilisateurs dans lequel vous effectuez la demande. Votre client d’application doit prendre en charge la connexion par des utilisateurs locaux Amazon Cognito ou par au moins un fournisseur d’identité tiers.
**`redirect_uri`**
Obligatoire.
URL vers laquelle le serveur d’authentification redirige le navigateur une fois qu’Amazon Cognito a autorisé l’utilisateur.
Un identificateur de ressource uniforme (URI) de redirection doit avoir les attributs suivants :
+ Il doit s’agir d’un URI absolu.
+ Vous devez avoir préalablement enregistré l’URI avec un client.
+ Il ne peut pas inclure un composant de fragment.
Voir [OAuth 2.0 - Point de terminaison de redirection](https://tools.ietf.org/html/rfc6749#section-3.1.2).
Amazon Cognito exige que votre URI de redirection utilise HTTPS, à l’exception de `http://localhost`, que vous pouvez définir comme URL de rappel à des fins de test.
Amazon Cognito prend également en charge le rappel d'applications telles URLs que. `myapp://example`
**`state`**
Facultatif, recommandé.
Lorsque votre application ajoute un paramètre *state* à une demande, Amazon Cognito renvoie sa valeur à votre application quand le point de terminaison `/oauth2/authorize` redirige votre utilisateur.
Ajoutez cette valeur à vos demandes afin de protéger votre système contre les attaques [CSRF](https://en.wikipedia.org/wiki/Cross-site_request_forgery) (cross-site request forgery, falsification de requête intersites).
Vous ne pouvez pas définir la valeur d’un paramètre `state` sur une chaîne JSON encodée par URL. Pour transmettre une chaîne correspondant à ce format dans un `state` paramètre, encodez-la en base64, puis décodez-la dans votre application.
**`identity_provider`**
Facultatif.
Ajoutez ce paramètre pour contourner la connexion gérée et rediriger votre utilisateur vers la page de connexion d'un fournisseur. La valeur du paramètre *identity\$1provider* est le nom du fournisseur d’identité, tel qu’il apparaît dans votre groupe d’utilisateurs.
+ Pour les fournisseurs sociaux, vous pouvez utiliser les valeurs *identity\$1provider*`Facebook`,`Google`, `LoginWithAmazon` et. `SignInWithApple`
+ Pour les groupes d'utilisateurs Amazon Cognito, utilisez la valeur. `COGNITO`
+ Pour les fournisseurs d'identité SAML 2.0 et OpenID Connect (OIDC) (IdPs), utilisez le nom que vous avez attribué à l'IdP dans votre groupe d'utilisateurs.
**`idp_identifier`**
Facultatif.
Ajoutez ce paramètre pour rediriger vers un fournisseur avec un autre nom pour le nom *identity\$1provider*. Vous pouvez saisir des identifiants pour votre SAML 2.0 et votre OIDC IdPs depuis le menu Réseaux **sociaux et fournisseurs externes** de la console Amazon Cognito.
**`scope`**
Facultatif.
Peut être une combinaison de tous les périmètres réservés au système ou personnalisées qui sont associées à un client. Les périmètres doivent être séparés par des espaces. Les périmètres dédiés à un système sont `openid`, `email`, `phone`, `profile` et `aws.cognito.signin.user.admin`. Tout périmètre utilisé doit être associé au client. Dans le cas contraire, il sera ignoré lors de l’exécution.
Si le client ne demande pas de périmètre, le serveur d’authentification utilise tous les périmètres associés au client.
Un jeton d’identification est renvoyé uniquement si le paramètre `openid` est demandé. Le jeton d’accès peut être utilisé pour des groupes d’utilisateurs Amazon Cognito que si le périmètre `aws.cognito.signin.user.admin` est demandé. Les paramètres scope `phone`, `email` et `profile` peuvent uniquement être demandés si le paramètre scope `openid` est également demandé. Ces paramètres scope régissent les revendications qui font partie du jeton d’identification.
**`code_challenge_method`**
Facultatif.
Le protocole de hachage que vous avez utilisé pour générer le défi. Le [PKCE RFC](https://tools.ietf.org/html/rfc7636) définit deux méthodes, S256 et « plain » . Cependant, le serveur d’authentification Amazon Cognito ne prend en charge que la méthode S256.
**`code_challenge`**
Facultatif.
Le défi de preuve d'échange de code clé (PKCE) que vous avez généré à partir du`code_verifier`. Pour de plus amples informations, veuillez consulter [Utilisation du PKCE dans l'octroi de codes d'autorisation](using-pkce-in-authorization-code.md).
Obligatoire uniquement lorsque vous spécifiez un paramètre `code_challenge_method`.
**`nonce`**
Facultatif.
Valeur aléatoire que vous pouvez ajouter à la demande. La valeur nonce que vous fournissez est incluse dans le jeton d’identification émis par Amazon Cognito. Pour se prémunir contre les attaques par rejeu, votre application peut inspecter la revendication `nonce` dans le jeton d’identification et la comparer à celle que vous avez générée. Pour de plus amples informations sur la revendication `nonce`, veuillez consulter [ID token validation](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation) (français non disponible) dans la *norme OpenID Connect*.
**`lang`**
Facultatif.
Langue dans laquelle vous souhaitez afficher les pages interactives avec l'utilisateur. Les pages de connexion gérées peuvent être localisées, mais pas les pages d'interface utilisateur hébergée (classiques). Pour de plus amples informations, veuillez consulter [Localisation des connexions gérées](cognito-user-pools-managed-login.md#managed-login-localization).
**`login_hint`**
Facultatif.
Une demande de nom d'utilisateur que vous souhaitez transmettre au serveur d'autorisation. Vous pouvez collecter un nom d'utilisateur, une adresse e-mail ou un numéro de téléphone auprès de votre utilisateur et autoriser le fournisseur de destination à prérenseigner le nom de connexion de l'utilisateur. Lorsque vous soumettez un `login_hint` paramètre et un numéro `idp_identifier` ou des `identity_provider` paramètres au point de `oauth2/authorize` terminaison, la connexion gérée remplit le champ du nom d'utilisateur avec votre valeur d'indice. Vous pouvez également transmettre ce paramètre au [Point de terminaison de connexion](login-endpoint.md) et remplir automatiquement la valeur du nom d'utilisateur.
Lorsque votre demande d'autorisation appelle une redirection vers OIDC IdPs, Amazon Cognito ajoute `login_hint` un paramètre à la demande à cet autorisateur tiers. Vous ne pouvez pas transférer les indications de connexion à SAML, Apple, Login With Amazon, Google ou Facebook (Meta) IdPs.
**`prompt`**
Facultatif.
Paramètre OIDC qui contrôle le comportement d'authentification pour les sessions existantes. Disponible uniquement dans la version de marque de connexion gérée, et non dans l'interface utilisateur hébergée classique. Pour plus d'informations sur la spécification OIDC, consultez la section [Demande d'authentification](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest). Les valeurs `none` `login` ont un effet sur le comportement d'authentification du groupe d'utilisateurs.
Amazon Cognito transmet toutes les valeurs de `prompt` sauf `none` à vous IdPs lorsque les utilisateurs sélectionnent l'authentification auprès de fournisseurs tiers. Cela est vrai lorsque l'URL à laquelle les utilisateurs accèdent inclut un `idp_identifier` paramètre `identity_provider` ou, ou lorsque le serveur d'autorisation les redirige vers le [Point de terminaison de connexion](login-endpoint.md) et ils sélectionnent un IdP parmi les boutons disponibles.
**Valeurs de paramètres rapides**
`prompt=none`
Amazon Cognito poursuit silencieusement l'authentification pour les utilisateurs disposant d'une session authentifiée valide. Grâce à cette invite, les utilisateurs peuvent s'authentifier silencieusement entre les différents clients d'applications de votre groupe d'utilisateurs. Si l'utilisateur n'est pas déjà authentifié, le serveur d'autorisation renvoie une `login_required` erreur.
`prompt=login`
Amazon Cognito demande aux utilisateurs de s'authentifier à nouveau même s'ils ont déjà une session. Envoyez cette valeur lorsque vous souhaitez vérifier à nouveau l'identité de l'utilisateur. Les utilisateurs authentifiés qui ont une session existante peuvent revenir à la connexion sans invalider cette session. Lorsqu'un utilisateur ayant une session existante se reconnecte, Amazon Cognito lui attribue un nouveau cookie de session. Ce paramètre peut également être transmis à votre IdPs. IdPsqui acceptent ce paramètre demandent également une nouvelle tentative d'authentification à l'utilisateur.
`prompt=select_account`
Cette valeur n'a aucun effet sur la connexion locale et doit être soumise dans les demandes redirigées vers IdPs. Lorsqu'il est inclus dans votre demande d'autorisation, ce paramètre `prompt=select_account` s'ajoute au chemin URL de la destination de redirection IdP. Lorsque ce paramètre est pris en IdPs charge, ils demandent aux utilisateurs de sélectionner le compte avec lequel ils souhaitent se connecter.
`prompt=consent`
Cette valeur n'a aucun effet sur la connexion locale et doit être soumise dans les demandes redirigées vers IdPs. Lorsqu'il est inclus dans votre demande d'autorisation, ce paramètre `prompt=consent` s'ajoute au chemin URL de la destination de redirection IdP. Lorsqu'ils IdPs prennent en charge ce paramètre, ils demandent le consentement de l'utilisateur avant de rediriger vers votre groupe d'utilisateurs.
Lorsque vous omettez le `prompt` paramètre dans votre demande, la connexion gérée suit le comportement par défaut : les utilisateurs doivent se connecter à moins que leur navigateur ne dispose d'un cookie de session de connexion gérée valide. Vous pouvez combiner plusieurs valeurs pour `prompt` avec un séparateur de caractères d'espace, par exemple. `prompt=login consent`
**`resource`**
Facultatif.
Identifiant d'une ressource que vous souhaitez associer au jeton d'accès dans la `aud` réclamation. Lorsque vous incluez ce paramètre, Amazon Cognito vérifie que la valeur est une URL et définit l'audience du jeton d'accès obtenu pour la ressource demandée. Vous pouvez demander un [serveur de ressources](cognito-user-pools-define-resource-servers.md) de pool d'utilisateurs avec un identifiant au format URL ou une URL de votre choix. Les valeurs de ce paramètre doivent commencer par `https://``http://localhost`, ou par un schéma d'URL personnalisé tel que`myapp://`.
La liaison de ressources est définie dans la [RFC 8707](https://www.rfc-editor.org/rfc/rfc8707.html). Pour plus d'informations sur les serveurs de ressources et les liaisons de ressources, consultez la section [Liaison de ressources](cognito-user-pools-define-resource-servers.md#cognito-user-pools-resource-binding).
## Exemple : octroi d'un code d'autorisation
Il s'agit d'un exemple de demande d'octroi de code d'autorisation.
La demande suivante lance une session pour récupérer un code d'autorisation que votre utilisateur transmet à votre application à `redirect_uri` destination. Cette session demande les champs d'application des attributs utilisateur et l'accès aux opérations de l'API en libre-service Amazon Cognito.
```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=code&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=openid+profile+aws.cognito.signin.user.admin
```
Le serveur d’authentification Amazon Cognito effectue une redirection vers votre application avec le code d’autorisation et l’état. Le code d'autorisation est valide pendant cinq minutes.
```
HTTP/1.1 302 Found
Location: https://www.example.com?code=a1b2c3d4-5678-90ab-cdef-EXAMPLE11111&state=abcdefg
```
## Exemple : octroi de code d'autorisation avec PKCE
Cet exemple de flux effectue l'octroi d'un code d'autorisation avec [PKCE.](using-pkce-in-authorization-code.md#using-pkce-in-authorization-code.title)
Cette demande ajoute un `code_challenge` paramètre. Pour terminer l'échange d'un code contre un jeton, vous devez inclure le `code_verifier` paramètre dans votre demande au `/oauth2/token` point de terminaison.
```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=code&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=aws.cognito.signin.user.admin&
code_challenge_method=S256&
code_challenge=a1b2c3d4...
```
Le serveur d'autorisation redirige vers votre application avec le code et l'état d'autorisation. Votre application traite le code d'autorisation et l'échange contre des jetons.
```
HTTP/1.1 302 Found
Location: https://www.example.com?code=a1b2c3d4-5678-90ab-cdef-EXAMPLE11111&state=abcdefg
```
## Exemple : exiger une nouvelle authentification avec `prompt=login`
La demande suivante ajoute un `prompt=login` paramètre qui oblige l'utilisateur à s'authentifier à nouveau, même s'il possède déjà une session.
```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=code&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=openid+profile+aws.cognito.signin.user.admin&
prompt=login
```
Le serveur d'autorisation redirige vers le point de [terminaison de connexion](login-endpoint.md), ce qui nécessite une nouvelle authentification.
```
HTTP/1.1 302 Found Location: https://mydomain.auth.us-east-1.amazoncognito.com/login?response_type=code&client_id=1example23456789&redirect_uri=https://www.example.com&state=abcdefg&scope=openid+profile+aws.cognito.signin.user.admin&prompt=login
```
## Exemple : authentification silencieuse avec `prompt=none`
La requête suivante ajoute un `prompt=none` paramètre qui vérifie silencieusement si la session de l'utilisateur est valide.
```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=code&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=openid+profile+aws.cognito.signin.user.admin&
prompt=none
```
Lorsqu'aucune session valide n'existe, le serveur d'autorisation renvoie une erreur à l'URI de redirection
```
HTTP/1.1 302 Found Location: https://www.example.com?error=login_required&state=abcdefg
```
Lorsqu'une session valide existe, le serveur d'autorisation renvoie un code d'autorisation.
```
HTTP/1.1 302 Found Location: https://www.example.com?code=AUTHORIZATION_CODE&state=abcdefg
```
## Exemple : octroi de code d'autorisation avec liaison de ressources
La demande suivante ajoute un `resource` paramètre pour lier le jeton d'accès à un serveur de ressources spécifique. Le jeton d'accès qui en résulte crée les conditions permettant à l'API cible de valider qu'il s'agit du public cible de la demande de l'utilisateur authentifié.
```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=code&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=solar-system-data-api.example.com/asteroids.add&
resource=https://solar-system-data-api.example.com
```
Le serveur d'autorisation renvoie un code d'autorisation qui se traduit par un jeton d'accès avec une `aud` réclamation de`https://solar-system-data-api.example.com`.
```
HTTP/1.1 302 Found Location: https://www.example.com?code=AUTHORIZATION_CODE&state=abcdefg
```
## Exemple : octroi de jetons (implicite) sans `openid` portée
Cet exemple de flux génère une autorisation implicite et retourne JWTs directement à la session de l'utilisateur.
La demande concerne une autorisation implicite de la part de votre serveur d'autorisation. Il demande dans le jeton d'accès des étendues qui autorisent les opérations en libre-service du profil utilisateur.
```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=token&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=aws.cognito.signin.user.admin
```
Le serveur d'autorisation redirige vers votre application avec un jeton d'accès uniquement. Comme la portée `openid` n’a pas été demandée, Amazon Cognito ne renvoie pas de jeton d’identification. De plus, Amazon Cognito ne renvoie pas de jeton d’actualisation dans ce flux.
```
HTTP/1.1 302 Found
Location: https://example.com/callback#access_token=eyJra456defEXAMPLE&token_type=bearer&expires_in=3600&state=STATE
```
## Exemple : subvention symbolique (implicite) avec `openid` portée
Cet exemple de flux génère une autorisation implicite et renvoie des jetons au navigateur de l'utilisateur.
La demande concerne une autorisation implicite de la part de votre serveur d'autorisation. Il demande dans le jeton d'accès des étendues qui autorisent l'accès aux attributs utilisateur et aux opérations en libre-service.
```
GET
https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=token&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=aws.cognito.signin.user.admin+openid+profile
```
Le serveur d'autorisation redirige vers votre application avec un jeton d'accès et un jeton d'identification (car le `openid` champ d'application a été inclus) :
```
HTTP/1.1 302 Found
Location: https://www.example.com#id_token=eyJra67890EXAMPLE&access_token=eyJra12345EXAMPLE&token_type=bearer&expires_in=3600&state=abcdefg
```
## Exemples de réponses négatives
Amazon Cognito peut refuser votre demande. Les demandes négatives sont accompagnées d'un code d'erreur HTTP et d'une description que vous pouvez utiliser pour corriger les paramètres de votre demande. Voici des exemples de réponses négatives.
+ Si `client_id` et `redirect_uri` sont valides, mais que les paramètres de la demande ne sont pas correctement formatés, le serveur d'authentification redirige l'erreur vers celle du client `redirect_uri` et ajoute un message d'erreur dans un paramètre d'URL. Voici des exemples de formatage incorrect.
+ La demande n'inclut aucun `response_type` paramètre.
+ La demande d'autorisation a fourni un `code_challenge` paramètre, mais pas un `code_challenge_method` paramètre.
+ La valeur du `code_challenge_method` paramètre ne l'est pas`S256`.
Voici la réponse à un exemple de demande dont le formatage est incorrect.
```
HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request
```
+ Si le client demande `code` ou reçoit `token` ces demandes`response_type`, mais qu'il n'est pas autorisé à les traiter, le serveur d'autorisation Amazon Cognito retourne `unauthorized_client` vers celui du client`redirect_uri`, comme suit :
```
HTTP 1.1 302 Found Location: https://client_redirect_uri?error=unauthorized_client
```
+ Si le client demande une portée inconnue, incorrecte ou non valide, le serveur d’autorisation Amazon Cognito renvoie `invalid_scope` à l’URI `redirect_uri` du client, comme suit :
```
HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_scope
```
+ En cas d'erreur inattendue sur le serveur, le serveur d'authentification `server_error` revient sur celui du client`redirect_uri`. Comme l'erreur HTTP 500 n'est pas envoyée au client, elle ne s'affiche pas dans le navigateur de l'utilisateur. Le serveur d'autorisation renvoie l'erreur suivante.
```
HTTP 1.1 302 Found Location: https://client_redirect_uri?error=server_error
```
+ Lorsqu'Amazon Cognito s'authentifie par le biais d'une fédération auprès d'un tiers, Amazon IdPs Cognito peut rencontrer des problèmes de connexion, tels que les suivants :
+ Si un délai de connexion se produit lors de la demande d’un jeton auprès du fournisseur d’identité, le serveur d’authentification redirige l’erreur vers l’URI `redirect_uri` du client de la façon suivante :
```
HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=Timeout+occurred+in+calling+IdP+token+endpoint
```
+ En cas d'expiration du délai de connexion lors de l'appel du `jwks_uri` point de terminaison pour la validation du jeton d'identification, le serveur d'authentification redirige avec une erreur vers celui du client `redirect_uri` comme suit :
```
HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=error_description=Timeout+in+calling+jwks+uri
```
+ Lors de l'authentification par fédération auprès d'un tiers IdPs, les fournisseurs peuvent renvoyer des réponses d'erreur. Cela peut être dû à des erreurs de configuration ou à d'autres raisons, telles que les suivantes :
+ Si une réponse d’erreur est reçue de la part d’autres fournisseurs, le serveur d’authentification redirige l’erreur vers le `redirect_uri` du client de la façon suivante :
```
HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=[IdP name]+Error+-+[status code]+error getting token
```
+ Si une réponse d'erreur est reçue de Google, le serveur d'authentification redirige l'erreur vers le `redirect_uri` du client de la façon suivante :
```
HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=Google+Error+-+[status code]+[Google-provided error code]
```
+ Lorsqu'Amazon Cognito rencontre une exception de communication lorsqu'il se connecte à un IdP externe, le serveur d'authentification redirige avec une erreur vers le client avec l'un `redirect_uri` des messages suivants :
+
```
HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=Connection+reset
```
+
```
HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=Read+timed+out
```
# 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`.
# Le point de terminaison des attributs utilisateur
Lorsque l'OIDC émet des jetons d'identification contenant des attributs utilisateur, la OAuth version 2.0 implémente le `/oauth2/userInfo` point de terminaison. Un utilisateur ou un client authentifié reçoit un jeton d'accès accompagné d'une `scopes` réclamation. Cette réclamation détermine les attributs que le serveur d'autorisation doit renvoyer. Lorsqu'une application présente un jeton d'accès au `userInfo` point de terminaison, le serveur d'autorisation renvoie un corps de réponse contenant les attributs utilisateur qui se situent dans les limites définies par les portées du jeton d'accès. Votre application peut récupérer des informations sur un utilisateur depuis le `userInfo` point de terminaison à condition qu'elle détienne un jeton d'accès valide avec au moins une revendication de `openid` portée.
Le point de terminaison `userInfo` est un [point de terminaison userInfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) OpenID Connect (OIDC). Il répond par des attributs utilisateur lorsque les fournisseurs de services présentent des jetons d'accès émis par votre [terminal de jeton](token-endpoint.md). Les portées du jeton d’accès de votre utilisateur définissent les attributs utilisateur que le point de terminaison userInfo renvoie dans sa réponse. La portée `openid` doit correspondre à l’une des demandes de jeton d’accès.
Amazon Cognito émet des jetons d’accès en réponse aux demandes d’API des groupes d’utilisateurs comme [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html). Comme ces jetons d’accès ne contiennent pas de portées, le point de terminaison userInfo ne les accepte pas. À la place, vous devez présenter les jetons d’accès de votre point de terminaison de jeton.
Votre fournisseur d'identité (IdP) tiers OAuth 2.0 héberge également un userInfo point de terminaison. Lorsque votre utilisateur s'authentifie auprès de cet IdP, Amazon Cognito échange silencieusement un code d'autorisation avec le point de terminaison de l'IdP. `token` Votre groupe d'utilisateurs transmet le jeton d'accès IdP pour autoriser la récupération des informations utilisateur depuis le point de terminaison IdP. `userInfo`
Les étendues du jeton d'accès d'un utilisateur sont déterminées par le paramètre de `scopes` demande dans les demandes d'authentification ou par les étendues ajoutées par le déclencheur [Lambda avant la génération du jeton](user-pool-lambda-pre-token-generation.md). Vous pouvez décoder les jetons d'accès et examiner les `scope` demandes pour connaître les étendues de contrôle d'accès qu'elles contiennent. Voici quelques combinaisons d'étendues qui influencent les données renvoyées par le `userInfo` point de terminaison. Le champ d'application Amazon Cognito réservé n'`aws.cognito.signin.user.admin`a aucun effet sur les données renvoyées par ce point de terminaison.Exemples de portées dans le jeton d'accès et leur effet sur la réponse `userInfo`
**`openid`**
Renvoie une réponse contenant tous les attributs utilisateur que le client de l'application peut lire.
**`openid profile`**
Renvoie les attributs utilisateur`name`,`family_name`,`given_name`,`middle_name`, `nickname``preferred_username`,`profile`,`picture`,`website`,`gender`,`birthdate`,`zoneinfo`,`locale`, et`updated_at`. Renvoie également [des attributs personnalisés](user-pool-settings-attributes.md#user-pool-settings-custom-attributes). Dans les clients d'application qui ne disposent pas d'un accès en lecture à chaque attribut, la réponse à cette portée est l'ensemble des attributs de la spécification auxquels votre client d'application a un accès en lecture.
**`openid email`**
Renvoie les informations de base du profil `email` et les `email_verified` attributs et.
**`openid phone`**
Renvoie les informations de base du profil `phone_number` et les `phone_number_verified` attributs et.
## GET /oauth2/userInfo
Votre application génère des requêtes directement vers ce point de terminaison, et non par le biais d'un navigateur.
Pour en savoir plus, consultez [Point de terminaison UserInfo](http://openid.net/specs/openid-connect-core-1_0.html#UserInfo) dans la spécification OpenID Connect (OIDC).
**Topics**
+ [GET /oauth2/userInfo](#get-userinfo)
+ [Paramètres de demande dans l’en-tête](#get-userinfo-request-header-parameters)
+ [Exemple — demande](#get-userinfo-positive-exchanging-authorization-code-for-userinfo-sample-request)
+ [Exemple — réponse positive](#get-userinfo-response-sample)
+ [Exemple de réponses négatives](#get-userinfo-negative)
## Paramètres de demande dans l’en-tête
**`Authorization: Bearer `**
Passez le jeton d'accès dans le champ d'en-tête d'autorisation.
Obligatoire.
## Exemple — demande
```
GET /oauth2/userInfo HTTP/1.1
Content-Type: application/x-amz-json-1.1
Authorization: Bearer eyJra12345EXAMPLE
User-Agent: [User agent]
Accept: */*
Host: auth.example.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
```
## Exemple — réponse positive
```
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Content-Length: [Integer]
Date: [Timestamp]
x-amz-cognito-request-id: [UUID]
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
Server: Server
Connection: keep-alive
{
"sub": "[UUID]",
"email_verified": "true",
"custom:mycustom1": "CustomValue",
"phone_number_verified": "true",
"phone_number": "+12065551212",
"email": "bob@example.com",
"username": "bob"
}
```
Pour obtenir la liste des revendications OIDC, consultez la référence aux [revendications standard](http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). Actuellement, Amazon Cognito renvoie les valeurs pour `email_verified` et `phone_number_verified` sous forme de chaînes.
## Exemple de réponses négatives
### Exemple — mauvaise demande
```
HTTP/1.1 400 Bad Request
WWW-Authenticate: error="invalid_request",
error_description="Bad OAuth2 request at UserInfo Endpoint"
```
**`invalid_request`**
Il manque un paramètre obligatoire à la demande, elle inclut une valeur de paramètre non prise en charge ou elle est mal formée.
### Exemple : mauvais jeton
```
HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="Access token is expired, disabled, or deleted, or the user has globally signed out."
```
**`invalid_token`**
Le jeton d'accès est expiré, révoqué, mal formé ou il n'est pas valide.
# Le point de terminaison de révocation des jetons
Les utilisateurs qui détiennent un jeton d'actualisation pendant leur session ont quelque chose de similaire à un cookie de navigateur. Ils peuvent renouveler leur session existante tant que le jeton d'actualisation est valide. Au lieu d'inviter un utilisateur à se connecter après l'expiration de son identifiant ou de son jeton d'accès, votre application peut utiliser le jeton d'actualisation pour obtenir de nouveaux jetons valides. Cependant, vous pouvez déterminer de manière externe que la session d'un utilisateur doit être terminée, ou l'utilisateur peut choisir d'oublier sa session en cours. À ce stade, vous pouvez révoquer ce jeton d'actualisation afin qu'ils ne puissent plus poursuivre leur session.
Le `/oauth2/revoke` point de terminaison révoque le jeton d'accès d'un utilisateur initialement émis par Amazon Cognito avec le jeton d'actualisation que vous fournissez. Ce point de terminaison révoque également le jeton d'actualisation lui-même et tous les jetons d'accès et d'identité ultérieurs du même jeton d'actualisation. Une fois que le terminal a révoqué les jetons, vous ne pouvez pas utiliser les jetons d'accès révoqués pour accéder APIs aux jetons Amazon Cognito authentifiés.
## POST /oauth2/revoke
Le point de terminaison `/oauth2/revoke` prend uniquement en charge `HTTPS POST`. Le client du groupe d’utilisateurs adresse les demandes directement à ce point de terminaison, et non via le navigateur du système.
### Paramètres de demande dans l’en-tête
**`Authorization`**
Si le client de votre application possède un secret client, l'application doit transmettre son code `client_id` et `client_secret` dans l'en-tête d'autorisation via l'autorisation HTTP de base. Le secret est [Basic](https://en.wikipedia.org/wiki/Basic_access_authentication#Client_side) `Base64Encode(client_id:client_secret)`.
**`Content-Type`**
Doit toujours être `'application/x-www-form-urlencoded'`.
#### Paramètres de la demande dans le corps
**`token`**
(Obligatoire) Le jeton d'actualisation que le client souhaite révoquer. La demande révoque également tous les jetons d’accès émis par Amazon Cognito avec ce jeton d’actualisation.
Obligatoire.
**`client_id`**
(Facultatif) L'ID client de l'application pour le jeton que vous souhaitez révoquer.
Obligatoire si le client est public et n’a pas de secret.
## Exemples de demandes de révocation
Cette demande de révocation révoque un jeton d'actualisation pour un client d'application qui n'a aucun secret client. Notez le `client_id` paramètre dans le corps de la demande.
```
POST /oauth2/revoke HTTP/1.1
Host: mydomain.auth.us-east-1.amazoncognito.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
token=2YotnFZFEjr1zCsicMWpAA&
client_id=1example23456789
```
Cette demande de révocation révoque un jeton d'actualisation pour un client d'application qui *possède* un secret client. Notez l'`Authorization`en-tête qui contient un identifiant client et un secret client codés, mais aucun `client_id` dans le corps de la demande.
```
POST /oauth2/revoke HTTP/1.1
Host: mydomain.auth.us-east-1.amazoncognito.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
token=2YotnFZFEjr1zCsicMWpAA
```
## Réponse d’erreur Révocation
Une réponse réussie contient un corps vide. La réponse d’erreur est un objet JSON avec un champ `error` et, dans certains cas, un champ `error_description`.
**Erreurs de point de terminaison**
+ Si le jeton n’est pas présent dans la demande ou si la fonction est désactivée pour le client d’application, vous recevez HTTP 400 et l’erreur `invalid_request`.
+ Si le jeton envoyé par Amazon Cognito dans la demande de révocation n’est pas un jeton d’actualisation, vous recevez HTTP 400 et l’erreur `unsupported_token_type`.
+ Si les informations d’identification du client ne sont pas valides, vous recevez HTTP 401 et l’erreur `invalid_client`.
+ Si le jeton a été révoqué ou si le client a soumis un jeton non valide, vous recevez HTTP 200 OK.
# Le point de terminaison d'assertion IDP SAML
Il `/saml2/idpresponse` reçoit des assertions SAML. Lors de la connexion service-provider-initiated (initiée par le SP), votre application n'interagit pas directement avec ce point de terminaison : votre fournisseur d'identité (IdP) SAML 2.0 redirige votre utilisateur ici avec sa réponse SAML. Pour une connexion initiée par le SP, configurez votre IdP avec le chemin d'accès à votre URL en `saml2/idpresponse` tant qu'URL du service client d'assertions (ACS). Pour plus d'informations sur le lancement de session, consultez[Lancement de séance SAML dans les groupes d'utilisateurs Amazon Cognito](cognito-user-pools-SAML-session-initiation.md).
Lors de la connexion initiée par l'IdP, appelez des demandes adressées à ce point de terminaison dans votre application après avoir connecté un utilisateur auprès de votre fournisseur SAML 2.0. Vos utilisateurs se connectent avec votre IdP dans leur navigateur, puis votre application collecte l'assertion SAML et la soumet à ce point de terminaison. Vous devez soumettre des assertions SAML dans le corps d'une `HTTP POST` demande via HTTPS. Le corps de votre `POST` demande doit être un `SAMLResponse` paramètre et un `Relaystate` paramètre. Pour de plus amples informations, veuillez consulter [Mettre en œuvre la connexion SAML initiée par l'IdP](cognito-user-pools-SAML-session-initiation.md#cognito-user-pools-SAML-session-initiation-idp-initiation).
Le `saml2/idpresponse` point de terminaison peut accepter des assertions SAML d'une longueur maximale de 100 000 caractères.
## POSTER `/saml2/idpresponse`
Pour utiliser le `/saml2/idpresponse` point de terminaison lors d'une connexion initiée par un IdP, générez une requête POST avec des paramètres qui fournissent à votre groupe d'utilisateurs des informations sur la session de votre utilisateur.
+ Le client d'application auquel ils souhaitent se connecter.
+ L'URL de rappel à laquelle ils veulent se retrouver.
+ Les étendues OAuth 2.0 qu'ils souhaitent demander dans le jeton d'accès de votre utilisateur.
+ L'IdP à l'origine de la demande de connexion.
### Paramètres du corps de la demande initiée par l'IDP
*SAMLResponse*
Une assertion SAML codée en Base64 provenant d'un IdP associé à un client d'application valide et à une configuration IdP dans votre groupe d'utilisateurs.
*RelayState*
Un `RelayState` paramètre contient les paramètres de demande que vous transmettriez autrement au `oauth2/authorize` point de terminaison. Pour obtenir plus d’informations sur ces paramètres, consultez [Point de terminaison d’autorisation](authorization-endpoint.md).
*response\$1type*
Le type de subvention OAuth 2.0.
*client\$1id*
ID du client d'application.
*redirect\$1uri*
URL vers laquelle le serveur d’authentification redirige le navigateur une fois qu’Amazon Cognito a autorisé l’utilisateur.
*identity\$1provider*
Le nom du fournisseur d'identité vers lequel vous souhaitez rediriger votre utilisateur.
*idp\$1identifier*
L'identifiant du fournisseur d'identité vers lequel vous souhaitez rediriger votre utilisateur.
*scope*
Les étendues OAuth 2.0 que vous souhaitez que votre utilisateur demande au serveur d'autorisation.
### Exemples de demandes avec réponses positives
**Exemple — requête POST**
La demande suivante concerne l'octroi d'un code d'autorisation à un utilisateur depuis l'IdP `MySAMLIdP` dans le client de l'application. `1example23456789` L'utilisateur redirige vers `https://www.example.com` avec son code d'autorisation, qui peut être échangé contre des jetons comprenant un jeton d'accès avec les portées OAuth 2.0 `openid``email`, et. `phone`
```
POST /saml2/idpresponse HTTP/1.1
User-Agent: USER_AGENT
Accept: */*
Host: example.auth.us-east-1.amazoncognito.com
Content-Type: application/x-www-form-urlencoded
SAMLResponse=[Base64-encoded SAML assertion]&RelayState=identity_provider%3DMySAMLIdP%26client_id%3D1example23456789%26redirect_uri%3Dhttps%3A%2F%2Fwww.example.com%26response_type%3Dcode%26scope%3Demail%2Bopenid%2Bphone
```
**Exemple — réponse**
Voici la réponse à la demande précédente.
```
HTTP/1.1 302 Found
Date: Wed, 06 Dec 2023 00:15:29 GMT
Content-Length: 0
x-amz-cognito-request-id: 8aba6eb5-fb54-4bc6-9368-c3878434f0fb
Location: https://www.example.com?code=[Authorization code]
```