Choses à faire

24h dans une journée, et tant de choses à faire !

Authentification en un clic avec OpenID et OAuth (3/3)

publié le 20 avril 2012 par Pierre Quillery

Pour cette dernière partie de notre série d’articles sur l’intégration d’OpenId et OAuth, je me propose d’aborder le cas de la connexion à un service OAuth à travers deux exemples complets qui devraient vous donner une petite idée du fonctionnement des API dans leur ensemble. En effet, comme je l’avais précisé en introduction de cette série, le protocole OAuth permet une implémentation beaucoup plus souple, ce qui signifie que si tous les services ont bel et bien une base commune, il y a des petites nuances.

Nous allons nous concentrer d’abord sur la connexion à Twitter qui me semble être la plus « pure » et la plus simple dans sa forme générale. Nous verrons dans un deuxième temps comme s’effectue la connexion à Facebook puis nous terminerons cet article en parlant des spécificités que vous rencontrerez en implémentant la connexion OAuth pour d’autres services.

Généralités

Pour bien suivre la suite de l’article, voilà quelques éléments qui devraient vous permettre d’y voir plus clair dans le fonctionnement général de la connexion avec OAuth. L’idée est de permettre à la plate-forme de votre choix d’identifier l’utilisateur à votre place. Pour ce faire, un certains nombre d’éléments vont devoir être échangés.

  • La plate-forme doit pouvoir vous identifier clairement en temps que partenaire, il est donc nécessaire de vous identifier clairement auprès d’elle pour obtenir des identifiants connus de vous seuls et que vous lui communiquerez en temps utiles.
  • Ceci étant fait, vous allez pouvoir établir un lien vers la plate-forme afin de lui demander d’identifier l’internaute de votre choix puis de revenir vers vous en appelant l’URL que vous lui aurez préalablement spécifiée. C’est elle qui s’occupe de connecter l’internaute puis de lui indiquer quels éléments il va partager avec vous (login, adresse mail, etc.).
  • Le processus d’identification étant achevé, l’application va revenir vers vous, avec soit un message d’erreur, soit un access_token : il s’agit d’un jeton temporaire qui va ensuite vous permettre d’obtenir les informations en interrogeant l’API du partenaire – notez qu’on sort alors du strict périmètre d’OAuth, qui n’est au final qu’un moyen d’obtenir ce access_token et rien de plus.

Choix de la librairie

Comme pour OpenID, l’utilisation d’une librairie va nous permettre d’encapsuler la majeure partie du comportement de la connexion OAuth ; j’ai utilisé avec succès OAuth-PHP en mode dit «two-legged» (c’est-à-dire qu’il ne repose pas sur une base de données pour fonctionner, ce qui vous laisse libre de votre implémentation).

Petit disclaimer : cette librairie a bien fonctionné sur l’ensemble des services OAuth avec lesquels j’ai eu l’occasion de travailler (Twitter, Facebook, Viadeo, Windows Live …), ce qui est en fait pour moi une référence. Néanmoins, un détail d’implémentation de l’API de LinkedIn semble poser un problème que je n’ai pas réussi à résoudre malgré toutes mes tentatives. J’ai dû me rabattre sur une API spécifique à LinkedIn qui fournissait en plus de la connexion la possibilité d’interroger l’API pour récupérer facilement des informations (elle reposait sur une autre implémentation de la connexion à OAuth).

Utilisation des boutons fournis par Twitter, Facebook, etc.

Les prestataires OAuth vous invitent à utiliser des boutons qu’ils ont conçu eux même, mais ceux-ci sont complexes à intégrer visuellement au reste de votre site et ajoutent généralement une feuille de style ou un javascript externe pour fonctionner, ce qui n’est pas très efficace ; surtout si la seule chose que vous voulez faire avec leurs APIs est d’établir une connexion.

Bonne nouvelle ! Il n’est absolument pas nécessaire d’utiliser ces boutons — pour mieux comprendre comment tout fonctionne, je vous conseille même de les ignorer purement et simplement dans un premier temps, car ils ne vous simplifieront pas la tâche et, au mieux vous permettront d’ouvrir un popup contenant le formulaire de connexion à votre place, court-circuitant ainsi l’étape de l’obtention du request_token qui est importante pour bien comprendre la démarche dans son ensemble.

Enregistrement de votre «application» sur le site tiers

La première étape est de vous connecter sur l’environnement de développement de l’API de votre choix afin d’y créer votre couple identifiant/mot de passe qui vous permettront d’établir une connexion : on parle généralement de la création d’une « application ». C’est également à ce niveau que vous pourrez paramétrer les informations (icône, description …) que l’internaute verra quand il sera invité à autoriser votre application à accéder à ses données personnelles.

Notez qu’il est le plus souvent nécessaire de créer de multiples « applications » si vous travaillez sur plusieurs environnement de développement, car elles ne sont souvent valables que pour un host unique. C’est le cas pour les deux services sur lesquels nous allons nous attarder, voyez donc ici pour twitter et ici pour facebook.

À la fin de ce processus vous allez récupérer deux éléments importants, votre clé d’utilisateur et votre mot de passe, ce dernier ne doit être connu que de vous seul. Vous devrez fournir ces deux éléments au fur et à mesure de votre connexion.

Twitter

Établissement de la connexion

Sans plus attendre, voici immédiatement le contenu de notre fichier connexion_twitter.php dont le rôle est essentiellement d’initier la connexion avec l’API de Twitter (obtention d’un request_token) puis de rediriger l’internaute vers un formulaire chez Twitter qui va lui permettre d’accepter de partager ses informations avec nous.

Retour de Twitter

Nous avons donc fourni à Twitter une URL de retour dans le paramètre oauth_callback : il va donc nous falloir gérer le retour de l’API après la connexion de l’internaute. Voilà donc le code de cette deuxième page :

Et voilà, notre internaute est connecté via Twitter 🙂 !

Facebook

Établissement de la connexion

L’établissement de la connexion à Facebook est plus simple que Twitter, car il n’y a pas de notion d’access_token : du coup, il s’agit simplement de rediriger sur le formulaire de Facebook en passant quelques paramètres en GET. Notez la présence du paramètre scope : il vous permet de demander immédiatement à l’internaute de partager des informations «sensibles» avec nous : l’email fait par exemple partie des éléments qui ne sont pas directement accessibles avec un access_token standard.

Retour de Facebook

L’internaute a accepté de partager des informations avec nous, nous allons donc utiliser le code retourné par l’API pour récupérer (enfin) le access_token que nous pourrons utiliser pour dialoguer avec l’API OpenGraph et récupérer finalement son email et les autres informations dont nous avons besoin.

En conclusion

Comme vous avez pu le constater par vous-même, OAuth permet de répondre efficacement aux problématiques qui ont conduit à sa création : support de multiple plate-formes, sécurisation de l’échange d’informations — le prix à payer est une configuration un peu plus longue en amont, et des subtilités d’implémentations qui varient d’un prestataire à l’autre (nécessité d’obtention d’un request_token, récupération complètement indépendante ou non des informations de l’internaute, etc.).

Les textes, illustrations et démonstrations présents sur ce site sont la propriété de leurs auteurs respectifs, sauf mention contraire (photo de la bannière).
Chosesafaire.fr, un site propulsé par Wordpress, vous est proposé par Pierre Quillery & Killian Ebel.

Valid XHTML 1.0 Strict