Passer au contenu principal

Connexion aux endpoints avec le flux « Authorization Code » OAuth 2.0 et PKCE

Comment se connecter aux endpoints

Pour authentifier vos utilisateurs, votre App doit implémenter un flux d’autorisation. Ce flux vous permet d’orienter vos utilisateurs vers une boîte de dialogue d’autorisation sur X. À partir de là, l’expérience principale de X affichera cette boîte de dialogue et prendra en charge l’autorisation au nom de votre App. Vos utilisateurs pourront autoriser votre App ou refuser l’autorisation. Une fois le choix effectué, X redirigera l’utilisateur vers votre App, où vous pourrez échanger le code d’autorisation contre un access token (si l’utilisateur a autorisé votre App) ou gérer un refus (si l’utilisateur ne l’a pas autorisée).

Travailler avec des clients confidentiels

Si vous travaillez avec des clients confidentiels, vous devrez utiliser un schéma de basic authentication pour générer un en-tête Authorization avec un encodage base64 lors de l’envoi de requêtes vers les endpoints de jeton. Les userid et password sont séparés par un seul caractère deux-points (”:”) dans une chaîne encodée en base64 au sein des informations d’identification. Un exemple ressemble à ceci : -header 'Authorization: Basic V1ROclFTMTRiVWhwTWw4M2FVNWFkVGQyTldNNk1UcGphUTotUm9LeDN4NThKQThTbTlKSXQyZm1BanEzcTVHWC1icVozdmpKeFNlR3NkbUd0WEViUA==' Si l’agent utilisateur souhaite envoyer le Client ID « Aladdin » et le mot de passe « open sesame », il utiliserait le champ d’en-tête suivant : Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Pour créer l’en-tête d’authentification Basic, vous devrez appliquer un encodage base64 à votre Client ID et à votre Client Secret, que vous pouvez obtenir depuis la page « Keys and Tokens » de votre App dans le developer portal.

Étapes pour se connecter avec OAuth 2.0

Étape 1 : Construire une URL d’autorisation Votre App doit construire une URL d’autorisation vers X, en indiquant les scopes dont votre App a besoin. Par exemple, si votre App doit consulter des Tweets, des utilisateurs et gérer les abonnements, elle doit demander les scopes suivants : tweet.read%20users.read%20follows.read%20follows.write L’URL contiendra également les paramètres code_challenge et state, en plus des autres paramètres requis. En production, utilisez une chaîne aléatoire pour le code_challenge. Étape 2 : GET oauth2/authorize Demandez à l’utilisateur de s’authentifier et d’envoyer à l’application un code d’autorisation. Si vous avez activé OAuth 2.0 pour votre App, vous pouvez trouver votre Client ID dans la page « Keys and Tokens » de votre App. Un exemple d’URL vers laquelle rediriger l’utilisateur ressemblerait à ceci :
https://x.com/i/oauth2/authorize?response_type=code&client_id=M1M5R3BMVy13QmpScXkzTUt5OE46MTpjaQ&redirect_uri=https://www.example.com&scope=tweet.read%20users.read%20follows.read%20follows.write&state=state&code_challenge=challenge&code_challenge_method=plain
Voici à quoi ressemblerait une URL d’exemple avec offline_access :
https://x.com/i/oauth2/authorize?response_type=code&client_id=M1M5R3BMVy13QmpScXkzTUt5OE46MTpjaQ&redirect_uri=https://www.example.com&scope=tweet.read%20users.read%20follows.read%20offline.access&state=state&code_challenge=challenge&code_challenge_method=plain
Après une authentification réussie, le redirect_uri recevra une requête contenant le paramètre auth_code. Votre application doit vérifier le paramètre state. Exemple de requête issue de la redirection du client :
https://www.example.com/?state=state&code=VGNibzFWSWREZm01bjN1N3dicWlNUG1oa2xRRVNNdmVHelJGY2hPWGxNd2dxOjE2MjIxNjA4MjU4MjU6MToxOmFjOjE
Étape 3 : POST oauth2/token - Access Token À ce stade, vous pouvez utiliser le code d’autorisation pour créer un access token et un refresh token (uniquement si la portée offline.access est demandée). Vous pouvez effectuer une requête POST vers l’endpoint suivant :
https://api.x.com/2/oauth2/token
Vous devrez transmettre l’en‑tête Content-Type avec la valeur application/x-www-form-urlencoded. De plus, votre requête doit inclure : code, grant_type, client_id, redirect_uri, ainsi que code_verifier. Voici un exemple de requête de jeton pour un client public :
curl --location --request POST 'https://api.x.com/2/oauth2/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'code=VGNibzFWSWREZm01bjN1N3dicWlNUG1oa2xRRVNNdmVHelJGY2hPWGxNd2dxOjE2MjIxNjA4MjU4MjU6MToxOmFjOjE' \
--data-urlencode 'grant_type=authorization_code' \
--data-urlencode 'client_id=rG9n6402A3dbUJKzXTNX4oWHJ' \
--data-urlencode 'redirect_uri=https://www.example.com' \
--data-urlencode 'code_verifier=challenge'
Voici un exemple avec un client confidentiel :
curl --location --request POST 'https://api.x.com/2/oauth2/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic V1ROclFTMTRiVWhwTWw4M2FVNWFkVGQyTldNNk1UcGphUTotUm9LeDN4NThKQThTbTlKSXQyZm1BanEzcTVHWC1icVozdmpKeFNlR3NkbUd0WEViUA=='\
--data-urlencode 'code=VGNibzFWSWREZm01bjN1N3dicWlNUG1oa2xRRVNNdmVHelJGY2hPWGxNd2dxOjE2MjIxNjA4MjU4MjU6MToxOmFjOjE' \
--data-urlencode 'grant_type=authorization_code' \
--data-urlencode 'redirect_uri=https://www.example.com' \
--data-urlencode 'code_verifier=challenge'
Étape 4 : Se connecter aux API Vous êtes maintenant prêt à vous connecter aux endpoints à l’aide d’OAuth 2.0. Pour ce faire, vous enverrez une requête à l’API comme vous le feriez avec l’authentification Jeton Bearer. Au lieu de transmettre votre Jeton Bearer, vous devez utiliser l’access token que vous avez généré à l’étape précédente. En réponse, vous devriez voir la charge utile appropriée correspondant à l’endpoint que vous interrogez. Cette requête est identique pour les clients publics et confidentiels. Voici à quoi ressemblerait un exemple de requête :
curl --location --request GET 'https://api.x.com/2/tweets?ids=1261326399320715264,1278347468690915330' \
--header 'Authorization: Bearer Q0Mzb0VhZ0V5dmNXSTEyNER2MFNfVW50RzdXdTN6STFxQlVkTGhTc1lCdlBiOjE2MjIxNDc3NDM5MTQ6MToxOmF0OjE'
Étape 5 : POST oauth2/token - renouveler le jeton Un jeton d’actualisation permet à une application d’obtenir un nouvel access token sans solliciter l’utilisateur. Vous pouvez générer un jeton d’actualisation en envoyant une requête POST à l’endpoint suivant : https://api.x.com/2/oauth2/token Vous devrez ajouter le Content-Type avec la valeur application/x-www-form-urlencoded dans un en-tête. En outre, vous devrez transmettre votre refresh_token, définir votre grant_type sur refresh_token, et préciser votre client_id. Cette requête fonctionne pour les clients publics :
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'
Voici un exemple pour les clients confidentiels :
POST 'https://api.x.com/2/oauth2/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic V1ROclFTMTRiVWhwTWw4M2FVNWFkVGQyTldNNk1UcGphUTotUm9LeDN4NThKQThTbTlKSXQyZm1BanEzcTVHWC1icVozdmpKeFNlR3NkbUd0WEViUA=='\
--data-urlencode 'refresh_token=bWRWa3gzdnk3WHRGU1o0bmRRcTJ5VUxWX1lZTDdJSUtmaWcxbTVxdEFXcW5tOjE2MjIxNDc3NDM5MTQ6MToxOnJ0OjE'\
--data-urlencode 'grant_type=refresh_token'
Étape 6 : POST oauth2/revoke - Révocation du jeton Un jeton de révocation invalide un access token ou un refresh token. Il est utilisé pour activer une fonctionnalité de « déconnexion » côté client, vous permettant de supprimer toutes les informations d’identification de sécurité associées au flux d’autorisation qui pourraient ne plus être nécessaires. Le jeton de révocation est destiné à une App pour révoquer un jeton, et non à un utilisateur. Vous pouvez créer une demande de révocation en envoyant une requête POST à l’URL suivante si l’App souhaite révoquer de manière programmatique l’accès qui lui a été accordé :
https://api.x.com/2/oauth2/revoke
Vous devrez transmettre l’en-tête Content-Type: application/x-www-form-urlencoded, ainsi que votre jeton et votre client_id. Dans certains cas, un utilisateur peut souhaiter révoquer l’accès accordé à une App. Il peut le faire en se rendant sur la page des Apps connectées.
curl --location --request POST 'https://api.x.com/2/oauth2/revoke' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'token=Q0Mzb0VhZ0V5dmNXSTEyNER2MFNfVW50RzdXdTN6STFxQlVkTGhTc1lCdlBiOjE2MjIxNDc3NDM5MTQ6MToxOmF0OjE' \
--data-urlencode 'client_id=rG9n6402A3dbUJKzXTNX4oWHJ'
Cette requête fonctionnera pour les clients confidentiels :
curl --location --request POST 'https://api.x.com/2/oauth2/revoke' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic V1ROclFTMTRiVWhwTWw4M2FVNWFkVGQyTldNNk1UcGphUTotUm9LeDN4NThKQThTbTlKSXQyZm1BanEzcTVHWC1icVozdmpKeFNlR3NkbUd0WEViUA=='\
--data-urlencode 'token=Q0Mzb0VhZ0V5dmNXSTEyNER2MFNfVW50RzdXdTN6STFxQlVkTGhTc1lCdlBiOjE2MjIxNDc3NDM5MTQ6MToxOmF0OjE'
I