Se connecter avec X

Utilisez Connexion avec X, également appelé Se connecter avec X, pour ajouter un bouton sur votre site ou votre application permettant aux utilisateurs de X de bénéficier des avantages d’un compte utilisateur enregistré en un clic ou presque. Cela fonctionne avec les sites web ainsi que les applications iOS, mobiles et de bureau.

​

Fonctionnalités

• Simplicité d’utilisation - Un nouveau visiteur de votre site n’a qu’à cliquer sur deux boutons pour se connecter pour la première fois.
• Intégration avec X - Le flux « Log in with X » peut accorder une autorisation pour utiliser les X API au nom de vos utilisateurs.
• Reposant sur OAuth - De nombreuses bibliothèques clientes et des exemples de code sont compatibles avec l’API « Log in with X ».

​

Disponible pour

• Navigateurs - Si vos utilisateurs peuvent accéder à un navigateur, vous pouvez intégrer Log in with X. En savoir plus sur le processus de connexion via navigateur.
• Appareils mobiles - Tout appareil mobile connecté à Internet peut tirer parti de Log in with X. En savoir plus sur le processus de connexion sur mobile.

​

Implémentation de « Log in with X »

Les implémentations sur navigateur et sur le Web mobile de Log in with X sont basées sur OAuth. Cette page présente les requêtes nécessaires pour obtenir un jeton d’accès pour le flux de connexion.

Pour utiliser le flux « Log in with X », veuillez vous rendre dans les paramètres de votre App X et vérifier que l’option « Allow this app to be used to Sign in with X? » est activée.

Cette page part du principe que le lecteur sait comment signer des requêtes à l’aide du protocole OAuth 1.0a. Si vous souhaitez savoir comment signer une requête, lisez la page Authorizing a request.

Si vous souhaitez vérifier la signature des requêtes sur cette page, le secret client utilisé est : L8qq9PZyRg6ieKGEKhZolGC0vJWLw8iEJ88DRdyOg. Cette valeur est destinée aux tests et ne fonctionnera pas pour de vraies requêtes.

Les trois étapes pour implémenter Log in with X — obtention d’un jeton de requête, redirection d’un utilisateur, puis conversion d’un jeton de requête en jeton d’accès — sont décrites ci-dessous.

Étape 1

​

Étape 1 : Obtention d’un jeton de requête

Pour démarrer un flux de connexion, votre App X doit obtenir un jeton de requête en envoyant un message signé à POST oauth/request_token. Le seul paramètre spécifique dans cette requête est oauth_callback, qui doit être cette URL encodée (URL-encoded) vers laquelle vous souhaitez que votre utilisateur soit redirigé lorsqu’il termine l’étape 2. Les autres paramètres sont ajoutés par le processus de signature OAuth.

Remarque : Toute URL de rappel que vous utilisez avec le point de terminaison POST oauth/request_token devra être enregistrée dans les paramètres de l’App X dans la Console de développement.

Exemple de requête (l’en-tête Authorization a été renvoyé à la ligne) :

POST /oauth/request_token HTTP/1.1
User-Agent: themattharris' HTTP Client
Host: api.x.com
Accept: */*
Authorization:
        OAuth oauth_callback="http%3A%2F%2Flocalhost%2Fsign-in-with-twitter%2F",
              oauth_consumer_key="cChZNFj6T5R0TigYB9yd1w",
              oauth_nonce="ea9ec8429b68d6b77cd5600adbbb0456",
              oauth_signature="F1Li3tvehgcraF8DMJ7OyxO4w9Y%3D",
              oauth_signature_method="HMAC-SHA1",
              oauth_timestamp="1318467427",
              oauth_version="1.0"

Votre App doit examiner le code d’état HTTP de la réponse. Toute valeur autre que 200 indique un échec. Le corps de la réponse contient les paramètres oauth_token, oauth_token_secret et oauth_callback_confirmed. Votre App doit vérifier que oauth_callback_confirmed est à true et stocker les deux autres valeurs pour les étapes suivantes.

Exemple de réponse (le corps de la réponse est présenté sur plusieurs lignes) :

HTTP/1.1 200 OK
Date: Thu, 13 Oct 2011 00:57:06 GMT
Status: 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 146
Pragma: no-cache
Expires: Tue, 31 Mar 1981 05:00:00 GMT
Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
Vary: Accept-Encoding
Server: tfe

oauth_token=NPcudxy0yU5T3tBzho7iCotZ3cnetKwcTIRlX0iwRl0&
oauth_token_secret=veNRnAWe6inFuo8o2u8SLLZLjolYDmDP7SzL0YfYI&
oauth_callback_confirmed=true

Étape 2

​

Étape 2 : rediriger l’utilisateur

La prochaine étape consiste à rediriger l’utilisateur vers X afin qu’il puisse suivre le flux approprié jusqu’à son terme, comme décrit dans le flux de connexion via navigateur ci-dessous. Redirigez l’utilisateur vers GET oauth/authenticate, et le jeton de requête obtenu à l’étape 1 doit être transmis en tant que paramètre oauth_token.

La manière la plus transparente pour un site web de l’implémenter est d’émettre une redirection HTTP 302 en réponse à la requête de « connexion » d’origine. Les applications mobiles et de bureau doivent ouvrir une nouvelle fenêtre de navigateur ou accéder à l’URL via une vue web intégrée.

Exemple d’URL vers laquelle rediriger :

https://api.x.com/oauth/authenticate?oauth_token=NPcudxy0yU5T3tBzho7iCotZ3cnetKwcTIRlX0iwRl0

Le point de terminaison de connexion se comportera de l’une des trois manières suivantes selon l’état de l’utilisateur :

1. Connecté et ayant déjà approuvé : si l’utilisateur est connecté sur x.com et a déjà approuvé l’application appelante, il sera immédiatement authentifié et renvoyé à l’URL de rappel avec un jeton de requête OAuth valide. La redirection vers x.com passe alors inaperçue pour l’utilisateur.
2. Connecté mais n’ayant pas approuvé : si l’utilisateur est connecté à x.com mais n’a pas approuvé l’application appelante, une demande de partage d’accès avec l’application appelante sera affichée. Après avoir accepté la demande d’autorisation, l’utilisateur sera redirigé vers l’URL de rappel avec un jeton de requête OAuth valide.
3. Non connecté : si l’utilisateur n’est pas connecté sur x.com, il sera invité à saisir ses identifiants et à accorder à l’application l’accès à ses informations sur le même écran. Une fois connecté, l’utilisateur sera renvoyé à l’URL de rappel avec un jeton de requête OAuth valide.

Après une authentification réussie, votre callback_url recevra une requête contenant les paramètres oauth_token et oauth_verifier. Votre application doit vérifier que le jeton correspond au jeton de requête reçu à l’étape 1.

Requête issue de la redirection du client (paramètres de chaîne de requête encapsulés) :

GET /sign-in-with-twitter/?
        oauth_token=NPcudxy0yU5T3tBzho7iCotZ3cnetKwcTIRlX0iwRl0&
        oauth_verifier=uw7NjWHT6OJ1MpJOXsHfNxoAhPKpgI8BlYDhxEjIBY HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/535.5 (KHTML, like Gecko) Chrome/16.0.891.1 Safari/535.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://localhost/sign-in-with-twitter/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Étape 3

​

Étape 3 : Conversion du jeton de requête en jeton d’accès

Pour convertir le jeton de requête en un jeton d’accès exploitable, votre application doit envoyer une requête au point de terminaison POST oauth/access_token, contenant la valeur oauth_verifier obtenue à l’étape 2. Le jeton de requête est également transmis dans la partie oauth_token de l’en-tête, mais celui-ci aura été ajouté par le processus de signature.

Exemple de requête (en-tête Authorization renvoyé à la ligne) :

POST /oauth/access_token HTTP/1.1
User-Agent: themattharris' HTTP Client
Host: api.x.com
Accept: */*
Authorization: OAuth oauth_consumer_key="cChZNFj6T5R0TigYB9yd1w",
                      oauth_nonce="a9900fe68e2573b27a37f10fbad6a755",
                      oauth_signature="39cipBtIOHEEnybAR4sATQTpl2I%3D",
                      oauth_signature_method="HMAC-SHA1",
                      oauth_timestamp="1318467427",
                      oauth_token="NPcudxy0yU5T3tBzho7iCotZ3cnetKwcTIRlX0iwRl0",
                      oauth_version="1.0"
Content-Length: 57
Content-Type: application/x-www-form-urlencoded

oauth_verifier=uw7NjWHT6OJ1MpJOXsHfNxoAhPKpgI8BlYDhxEjIBY

Une réponse réussie contient les paramètres oauth_token et oauth_token_secret. Le token et son secret doivent être stockés et utilisés pour les futures requêtes authentifiées vers l’API X. Pour déterminer l’identité de l’utilisateur, utilisez GET account/verify_credentials.

Exemple de réponse (le corps de la réponse a été adapté pour la lisibilité) :

HTTP/1.1 200 OK
Date: Thu, 13 Oct 2011 00:57:08 GMT
Status: 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 157
Pragma: no-cache
Expires: Tue, 31 Mar 1981 05:00:00 GMT
Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
Vary: Accept-Encoding
Server: tfe

oauth_token=7588892-kagSNqWge8gB1WwE3plnFsJHAZVfxWD7Vb57p0b4&
oauth_token_secret=PbKfYqSryyeKDWz4ebtY3o5ogNLG11WJuZBc9fQrQo

Ressources supplémentaires

​

Ressources pour « Se connecter avec X »

​

Bibliothèques Client

Les bibliothèques client répertoriées dans X libraries vous aideront à implémenter la fonctionnalité « Se connecter avec X ». Utilisez le endpoint /oauth/authenticate, comme décrit dans les étapes précédentes.

​

Brand Toolkit

X préfère que votre application utilise le X Brand Toolkit officiel pour une image de marque cohérente. Enregistrez ces ressources et utilisez‑les lorsque vous créez un bouton « Login with X ».

Flux de connexion via le navigateur

Le flux de connexion via le navigateur convient aux sites web et aux applications capables d’ouvrir ou d’intégrer un navigateur web. À un niveau très général :

• L’application affiche un lien ou un bouton « Sign in with X ».
• L’utilisateur clique sur le bouton de connexion.
• Le navigateur web actuel est redirigé vers X (ou un nouveau navigateur est ouvert et dirigé vers X).
• L’utilisateur effectue, si nécessaire, une étape de connexion et d’autorisation sur X.
• X redirige vers une URL contrôlée par l’application, en transmettant les informations d’autorisation pour l’utilisateur.

X conserve l’historique des autorisations, de sorte que pour les utilisateurs déjà connectés à X.com qui ont autorisé l’application, aucune interface n’est affichée ; ils sont automatiquement redirigés vers l’application.

​

Flux sur ordinateur de bureau

Pour illustrer ces flux, imaginons que le site web représenté ci‑dessus (« The greatest website ever created ») a implémenté cette API, comme l’indique le bouton « Sign in with X » sur la page d’accueil.

Lorsque l’utilisateur clique sur le bouton « Sign in », la page qu’il voit dépend du fait qu’il soit connecté ou non et qu’il ait déjà autorisé ou non l’application à accéder à son compte.

Lorsque l’utilisateur est connecté à x.com mais n’a pas accordé d’accès, une liste des autorisations demandées, accompagnée des boutons « Sign In » et « Cancel », est affichée.

Lorsque l’utilisateur n’est pas connecté à x.com, des champs de saisie pour un nom d’utilisateur et un mot de passe sont affichés. Notez que même si l’utilisateur a déjà accordé l’accès à l’application, la liste des autorisations sera toujours affichée.

Après que l’utilisateur a saisi des identifiants valides (si nécessaire) et cliqué sur « Sign In », X redirige l’utilisateur vers le site web qui a lancé le flux de connexion.

Dans le cas où l’utilisateur est déjà connecté à x.com et a accordé l’accès au site web, cette redirection se produit immédiatement.

Flux de connexion sur mobile

Le flux d’interface utilisateur pour les navigateurs web mobiles fonctionne exactement comme le flux de connexion via le navigateur, mais il est optimisé pour les navigateurs mobiles.

Ci‑dessous figurent des captures d’écran pour les écrans connecté, déconnecté et de redirection :