Flux d’autorisation OAuth 2.0 avec code et PKCE

​

Flux de code d’autorisation OAuth 2.0 avec PKCE

​

Introduction

OAuth 2.0 est un protocole d’autorisation standard du secteur qui offre un meilleur contrôle de la portée d’une application et des flux d’autorisation sur plusieurs appareils. OAuth 2.0 vous permet de sélectionner des portées granulaires et spécifiques qui vous confèrent des autorisations précises au nom d’un utilisateur.

Pour activer OAuth 2.0 dans votre App, vous devez l’activer dans les paramètres d’authentification de votre App, accessibles dans la section App settings du developer portal.

​

Pendant combien de temps mes identifiants resteront-ils valides ?  

Par défaut, l’access token que vous créez via le flux Authorization Code avec PKCE n’est valide que pendant deux heures, sauf si vous avez utilisé le scope offline.access.

​

Jetons d’actualisation

Les jetons d’actualisation permettent à une application d’obtenir un nouvel access token sans solliciter l’utilisateur, via le flux de renouvellement.

Si la portée offline.access est appliquée, un jeton d’actualisation OAuth 2.0 sera émis. Avec ce jeton d’actualisation, vous obtenez un access token. Si cette portée n’est pas transmise, nous ne générerons pas de jeton d’actualisation.

Voici un exemple de requête à utiliser pour obtenir un nouvel access token à l’aide d’un jeton d’actualisation :

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 définir l’authentification de votre App sur 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 la 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 peuvent conserver des informations d’identification de manière sécurisée sans les exposer à des tiers non autorisés et s’authentifier en toute sécurité auprès du serveur d’autorisation, ce qui permet de protéger votre secret client. Les clients publics, qui s’exécutent généralement dans un navigateur ou sur un appareil mobile, ne peuvent pas utiliser vos secrets client. Si vous sélectionnez un type d’App qui est un client confidentiel, un secret client vous sera fourni.

Si vous avez sélectionné, dans le developer portal, un type de client de type confidentiel, vous pourrez également voir un secret client. Vos options sont Native App, Single page App, Web App, Automated App ou bot. Les Native App et Single page App sont des clients publics, tandis que les Web App et Automated App ou les bots sont des clients confidentiels.

Vous n’avez pas besoin de l’id client pour les clients confidentiels lorsque l’en-tête Authorization est valide. Vous devez toujours inclure Client Id dans le corps des requêtes pour 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 nécessaires. Pour en savoir plus sur la correspondance entre les scopes et les endpoints, consultez notre guide de correspondance d’authentification.

Scope	Description
tweet.read	Tous les Tweets que vous pouvez consulter, y compris ceux de comptes protégés.
tweet.write	Publier des Tweets et effectuer des Retweet pour vous.
tweet.moderate.write	Masquer et réafficher les réponses à vos Tweets.
users.email	Adresse e‑mail d’un utilisateur authentifié.
users.read	Tous les comptes que vous pouvez consulter, y compris les comptes protégés.
follows.read	Les personnes qui vous suivent et celles que vous suivez.
follows.write	Suivre et ne plus suivre des personnes pour vous.
offline.access	Rester connecté à votre compte jusqu’à ce que vous révoquiez l’accès.
space.read	Tous les Spaces que vous pouvez consulter.
mute.read	Comptes que vous avez mis en sourdine.
mute.write	Mettre en sourdine et réactiver des comptes pour vous.
like.read	Tweets que vous avez likés et likes que vous pouvez consulter.
like.write	Aimer et retirer des likes de Tweets pour vous.
list.read	Lists, membres de Lists et abonnés des Lists que vous avez créées ou dont vous êtes membre, y compris les Lists privées.
list.write	Créer et gérer des Lists pour vous.
block.read	Comptes que vous avez bloqués.
block.write	Bloquer et débloquer des comptes pour vous.
bookmark.read	Récupérer les Tweets enregistrés en signet d’un utilisateur authentifié.
bookmark.write	Ajouter et supprimer des signets sur des Tweets.
media.write	Importer des médias.

​

Limites de taux

Dans l’ensemble, les limites de taux sont identiques à celles utilisées avec OAuth 1.0a, à l’exception des recherches de Tweets et des recherches d’utilisateurs. Nous augmentons la limite par App de 300 à 900 requêtes par tranche de 15 minutes avec 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.

​

Types d’autorisation

Pour ce lancement initial, nous prenons uniquement en charge le code d’autorisation avec PKCE et le jeton d’actualisation comme types d’autorisation. D’autres types d’autorisation pourront être pris en charge à l’avenir.

​

Parcours OAuth 2.0

OAuth 2.0 suit un parcours similaire à celui que nous utilisons actuellement pour OAuth 1.0a. Vous pouvez consulter un diagramme et une explication détaillée dans notre documentation sur le sujet. 

​

Glossaire

Terme	Description
Types de grant	Le cadre OAuth définit plusieurs types de grant pour différents cas d’usage ainsi qu’un mécanisme pour en créer de nouveaux. Exemples : authorization code, client credentials, device code et refresh token.
Client confidentiel	Les clients sont des applications capables de s’authentifier de façon sécurisée auprès du serveur d’autorisation, par exemple en conservant en sécurité leur client secret enregistré.
Client public	Clients ne pouvant pas utiliser de client secrets enregistrés, comme les applications s’exécutant dans un navigateur ou sur un appareil mobile.
Flux authorization code	Utilisé par les clients confidentiels et publics pour échanger un authorization code contre un access token.
PKCE	Une extension du flux authorization code visant à prévenir plusieurs attaques et à permettre d’effectuer l’échange OAuth de manière sécurisée depuis des clients publics.
Client ID	Disponible dans la section clés et jetons du developer portal 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 authorize.
Redirect URI	Votre URL de rappel (callback). Vous devrez disposer de la validation de correspondance exacte.
Authorization code	Permet à une application d’appeler des API au nom d’utilisateurs. Également appelé auth_code. Le auth_code a une durée de validité de 30 secondes après que le propriétaire de l’App a reçu un auth_code approuvé de l’utilisateur. Vous devrez l’échanger contre un access token dans les 30 secondes, faute de quoi le auth_code expirera.
Access token	Les Access Tokens sont les jetons que les applications utilisent pour effectuer des requêtes API au nom d’un utilisateur.
Refresh token	Permet à une application d’obtenir un nouvel access token sans solliciter l’utilisateur via le flux de refresh token.
Client Secret	Si vous avez sélectionné un type d’App de catégorie client confidentiel, un « Client Secret » vous sera fourni sous « Client ID » dans la section clés et jetons de votre App.

​

Paramètres

Pour construire une URL d’autorisation OAuth 2.0, assurez-vous d’inclure les paramètres suivants dans l’URL d’autorisation.

Paramètre	Description
response_type	Indiquez que le type est un code avec le mot « code ».
client_id	Disponible dans le developer portal sous l’intitulé « Client ID ».
redirect_uri	Votre URL de rappel (callback). Cette valeur doit correspondre à l’une des Callback URLs définies dans les paramètres de votre App. Pour OAuth 2.0, vous devez appliquer une validation de correspondance exacte pour votre URL de rappel.
state	Une chaîne aléatoire que vous fournissez pour vous prémunir contre les attaques CSRF. La longueur de cette chaîne peut atteindre 500 caractères.
code_challenge	Un paramètre PKCE, un secret aléatoire pour chaque requête que vous effectuez.
code_challenge_method	Indique la méthode utilisée pour la requête (S256 ou plain).

​

URL d’autorisation 

Avec OAuth 2.0, vous générez 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 devez utiliser l’encodage approprié pour que cette URL fonctionne. Veillez à consulter notre documentation sur l’encodage pourcentage.