> ## Documentation Index
> Fetch the complete documentation index at: https://generaltranslation.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Flux de code d’autorisation OAuth 2.0 avec PKCE
### Flux de code d’autorisation OAuth 2.0 avec PKCE
#### Introduction
OAuth 2.0 est un protocole d’autorisation standard du secteur qui permet un contrôle plus précis sur le périmètre d’accès d’une application et sur les flux d’autorisation sur plusieurs appareils. OAuth 2.0 vous permet de choisir des périmètres d’accès (scopes) fins et spécifiques, qui vous donnent des autorisations précises pour le compte d’un utilisateur.
Pour activer OAuth 2.0 pour votre App, vous devez l’activer dans les paramètres d’authentification de votre App, accessibles dans la section App settings de la Console de développement.
#### Pendant combien de temps mes identifiants resteront-ils valides ?
Par défaut, le jeton d’accès que vous créez via le flux d’autorisation Authorization Code Flow with PKCE n’est valide que pendant deux heures, sauf si vous avez utilisé la portée `offline.access`.
#### Jetons d’actualisation
Les jetons d’actualisation permettent à une application d’obtenir un nouveau jeton d’accès sans solliciter l’utilisateur, via le flux d’actualisation.
Si le scope `offline.access` est appliqué, un jeton d’actualisation OAuth 2.0 sera émis. Grâce à ce jeton d’actualisation, vous pouvez obtenir un jeton d’accès. Si ce scope n’est pas transmis, nous ne générerons pas de jeton d’actualisation.
Voici un exemple de requête à envoyer pour utiliser un jeton d’actualisation afin d’obtenir un nouveau jeton d’accès :
```bash theme={null}
POST 'https://api.x.com/2/oauth2/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'refresh_token=bWRWa3gzdnk3WHRGU1o0bmRRcTJ5VUxWX1lZTDdJSUtmaWcxbTVxdEFXcW5tOjE2MjIxNDc3NDM5MTQ6MToxOnJ0OjE' \
--data-urlencode 'grant_type=refresh_token' \
--data-urlencode 'client_id=rG9n6402A3dbUJKzXTNX4oWHJ
```
#### Paramètres de l’App
Vous pouvez configurer les paramètres d’authentification de votre App pour utiliser OAuth 1.0a ou OAuth 2.0. Vous pouvez également autoriser une App à utiliser à la fois OAuth 1.0a et OAuth 2.0.
OAuth 2.0 ne peut être utilisé qu’avec X API v2. Si vous avez sélectionné OAuth 2.0, vous verrez un Client ID dans la section Keys and Tokens de votre App.
#### Clients confidentiels
[Les clients confidentiels](https://datatracker.ietf.org/doc/html/rfc6749#section-2.1) peuvent conserver des identifiants de façon sécurisée sans les exposer à des tiers non autorisés et s’authentifier de manière sécurisée auprès du serveur d’autorisation, ce qui permet de garder votre Client Secret en sécurité. Les clients publics, qui s’exécutent généralement dans un navigateur ou sur un appareil mobile, ne peuvent pas utiliser vos Client Secrets. Si vous sélectionnez un type d’App qui est un client confidentiel, un Client Secret vous sera fourni.
Si vous avez sélectionné un type de client qui est un client confidentiel dans la Console de développement, vous verrez également un Client Secret. Vos options sont Native App, Single page App, Web App, Automated App ou bot. Les Native App et Single page Apps sont des clients publics, et les Web App et Automated App ou bots sont des clients confidentiels.
Vous n’avez pas besoin de client id pour les clients confidentiels avec un en-tête Authorization valide. Vous devez toujours inclure le Client Id dans le corps des requêtes avec un client public.
#### Scopes
Les scopes vous permettent de définir un accès granulaire pour votre App afin qu’elle ne dispose que des autorisations dont elle a besoin. Pour en savoir plus sur la correspondance entre les scopes et les endpoints, consultez notre [guide de correspondance d’authentification](/fr/resources/fundamentals/authentication/guides/v2-authentication-mapping).
| | |
| :------------------- | :--------------------------------------------------------------------------------------------------------------------------- |
| **Scope** | **Description** |
| tweet.read | Tous les Tweets que vous pouvez voir, y compris les Tweets de comptes protégés. |
| tweet.write | Tweeter et Retweeter en votre nom. |
| tweet.moderate.write | Masquer et réafficher les réponses à vos Tweets. |
| users.email | Adresse e-mail d’un utilisateur authentifié. |
| users.read | Tout compte que vous pouvez voir, y compris les comptes protégés. |
| follows.read | Les personnes qui vous suivent et les personnes que vous suivez. |
| follows.write | Suivre et ne plus suivre des personnes en votre nom. |
| offline.access | Rester connecté à votre compte jusqu’à ce que vous révoquiez l’accès. |
| space.read | Tous les Espaces que vous pouvez voir. |
| mute.read | Comptes que vous avez mis en sourdine. |
| mute.write | Mettre en sourdine et réactiver des comptes en votre nom. |
| like.read | Tweets que vous avez aimés et mentions « J’aime » que vous pouvez voir. |
| like.write | Ajouter et retirer des mentions « J’aime » sur des Tweets en votre nom. |
| list.read | Listes, membres de listes et abonnés aux listes que vous avez créées ou dont vous êtes membre, y compris les listes privées. |
| list.write | Créer et gérer des listes en votre nom. |
| block.read | Comptes que vous avez bloqués. |
| block.write | Bloquer et débloquer des comptes en votre nom. |
| bookmark.read | Récupérer les Tweets ajoutés aux signets par un utilisateur authentifié. |
| bookmark.write | Ajouter des Tweets aux signets et en retirer. |
| media.write | Téléverser des médias. |
#### Limites de taux
Dans l’ensemble, les limites de taux sont identiques à celles appliquées lors de l’authentification avec OAuth 1.0a, à l’exception de la recherche de Tweets et de la recherche d’utilisateurs. Nous portons la limite par App de 300 à 900 requêtes par tranche de 15 minutes lorsque vous utilisez OAuth 2.0 pour la recherche de Tweets et la recherche d’utilisateurs. Pour en savoir plus, consultez notre [documentation sur les limites de taux](/fr/resources/fundamentals/rate-limits).
#### Types de flux d’autorisation
Pour ce lancement initial, nous proposons uniquement le [code d’autorisation](https://oauth.net/2/grant-types/authorization-code/) avec [PKCE](https://oauth.net/2/pkce/) et le [jeton d’actualisation](https://oauth.net/2/grant-types/refresh-token/) comme [types de flux d’autorisation](https://oauth.net/2/grant-types/) pris en charge. Nous pourrons proposer d’autres types de flux d’autorisation à l’avenir.
#### Flux OAuth 2.0
OAuth 2.0 utilise un flux similaire au flux que nous utilisons actuellement pour OAuth 1.0a. Vous pouvez consulter un schéma et une explication détaillée dans notre [documentation sur ce sujet](/fr/resources/fundamentals/authentication/oauth-1-0a/obtaining-user-access-tokens).
#### Glossaire
| | |
| :---------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Terme** | **Description** |
| Grant types | La spécification OAuth définit plusieurs types de « grant » pour différents cas d’usage, ainsi qu’un cadre pour en créer de nouveaux. Parmi eux : authorization code, client credentials, device code et refresh token. |
| Confidential client | Les clients confidentiels sont des applications qui peuvent s’authentifier de manière sécurisée auprès du serveur d’autorisation, par exemple en conservant leur client secret enregistré en sécurité. |
| Public client | Les clients publics ne peuvent pas utiliser de client secrets enregistrés, comme les applications exécutées dans un navigateur ou sur un appareil mobile. |
| Authorization code flow | Flux utilisé par les clients confidentiels et publics pour échanger un code d’autorisation contre un access token. |
| PKCE | Extension de l’authorization code flow qui empêche plusieurs types d’attaques et permet d’effectuer l’échange OAuth de manière sécurisée depuis des clients publics. |
| Client ID | Peut être trouvé dans la section des clés et des jetons de la Console de développement sous l’en-tête « Client ID ». Si vous ne le voyez pas, veuillez contacter directement notre équipe. Le Client ID sera nécessaire pour générer l’URL d’autorisation. |
| Redirect URI | Votre URL de rappel (callback URL). Vous devrez utiliser la [validation de correspondance exacte](https://datatracker.ietf.org/doc/html/rfc6749#section-10.6). |
| Authorization code | Permet à une application d’appeler les API au nom des utilisateurs. Appelé auth\_code. L’auth\_code a une durée de validité de 30 secondes à compter du moment où le propriétaire de l’App reçoit un auth\_code approuvé de l’utilisateur. Vous devrez l’échanger contre un access token dans les 30 secondes, faute de quoi l’auth\_code expirera. |
| Access token | Les access tokens sont les jetons que les applications utilisent pour effectuer des requêtes d’API au nom d’un utilisateur. |
| Refresh token | Permet à une application d’obtenir un nouvel access token sans solliciter l’utilisateur, via le refresh token flow. |
| Client Secret | Si vous avez sélectionné un type d’App qui est un confidential client, un « Client Secret » vous sera fourni sous « Client ID » dans la section des clés et des jetons de votre App. |
#### Paramètres
Pour construire une URL d’autorisation OAuth 2.0, vous devez vous assurer que les paramètres suivants sont présents dans l’URL d’autorisation.
| | |
| :---------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Paramètre** | **Description** |
| response\_type | Vous devez indiquer qu’il s’agit d’un code avec le mot « code ». |
| client\_id | Vous pouvez le trouver dans la Console de développement sous l’en-tête « Client ID ». |
| redirect\_uri | Votre URL de rappel. Cette valeur doit correspondre à l’une des URLs de rappel définies dans les paramètres de votre App. Pour OAuth 2.0, vous devez disposer d’une [validation de correspondance exacte](https://datatracker.ietf.org/doc/html/rfc6749#section-10.6) pour votre URL de rappel. |
| state | Une chaîne aléatoire que vous fournissez pour vous protéger contre les [attaques CSRF](https://auth0.com/docs/protocols/state-parameters). La longueur de cette chaîne peut aller jusqu’à 500 caractères. |
| code\_challenge | Un paramètre [PKCE](https://www.oauth.com/oauth2-servers/pkce/authorization-request/), un secret aléatoire propre à chaque requête que vous effectuez. |
| code\_challenge\_method | Indique la méthode que vous utilisez pour effectuer une requête (S256 OU plain). |
#### URL d’autorisation
Avec OAuth 2.0, vous créez une URL d’autorisation que vous pouvez utiliser pour permettre à un utilisateur de s’authentifier via un flux d’authentification, similaire à « Se connecter avec X ».
Voici un exemple de l’URL que vous allez créer :
```
https://x.com/i/oauth2/authorize?response_type=code&client_id=M1M5R3BMVy13QmpScXkzTUt5OE46MTpjaQ&redirect_uri=https://www.example.com&scope=tweet.read%20users.read%20account.follows.read%20account.follows.write&state=state&code_challenge=challenge&code_challenge_method=plain
```
Vous devrez utiliser l’encodage approprié pour que cette URL fonctionne. Veillez à consulter notre documentation sur l’[encodage pourcentuel](/fr/resources/fundamentals/authentication/oauth-1-0a/percent-encoding-parameters).