Le protocole d'authentification OAuth (Open Authorization) : principes généraux

Lors d'une de mes missions, j'ai été amené à mettre en œuvre des autorisations de type OAuth. Ceci dans le cadre d'un développement lié aux API du Web 2.0 telles que l'API de Twitter ou Yammer. Beaucoup d'applications du monde Web 2.0 ont fait le choix de mettre en place des autorisations d'accès de type OAuth. C'est pour cette raison que j'ai souhaité en parler dans ce billet. En effet, lors d'une première découverte, les principes de fonctionnement de l'Open Authirization ne sont pas si évident à bien comprendre.

OAuth est en fait un protocole qui permet l'authentification pour un utilisateur donné entre une application Web que vous êtes entrain de développer et une application du Web 2.0 (Twitter, Yammer, ...). Une fois l'autorisation accordée, cet utilisateur pourra avoir accès directement à l'application Web 2.0 sans avoir à s'authentifier à nouveau. Cela ressemble étrangement à un type d'identification, que j'avais rencontré au début de ma carrière, qui est le SSO (Single Sign On) avec CAS (Central Authentication Service). Celui-ci fonctionnait aussi à l'aide de jetons d'accès. Dans la suite de ce billet, je vais vous présenter comment OAuth fonctionne de manière générale.

OAuth est en fait une autorisation particulière basée sur des jetons (ou Token) et un droit d'accès manuel à l'initiative de l'utilisateur. Elle se fait en 3 étapes :

• Etape 1 : il faut déclarer la nouvelle application que vous êtes entrain de développer sur le site avec lequel vous souhaitez vous connecter (Twitter, Yammer, ...). Suite à cette déclaration, l'application vous fournie un code de consommation (Consumer Code en anglais) avec un mot de passe (Secret en anglais).
• Etape 2 : A l'aide de ces codes, vous pouvez attaquer une URL spécifique fournie par l'application Web 2.0 (voir la documentation de l'API associée) à laquelle vous souhaitez vous connecter. En règle générale, l'API repose sur une architecture logicielle de type REST (cf. mon billet sur le sujet pour plus d'informations ). En retour, vous devriez avoir un jeton de requête temporaire (Request Token en anglais) et un mot de passe associé.
• Etape 3 : Ce jeton avec son mot de passe associé vous permet de vous connecter sur une autre URL spécifique de l'application Web 2.0 (voir aussi la documentation de l'API pour retrouver cette URL). Cette étape est normalement manuelle c'est à dire que vous devez vous connecter à l'URL en passant par votre navigateur Web préféré. A ce moment là, l'application Web 2.0 vous demande de vous connecter avec votre login/mot de passe habituel (si vous ne l'êtes pas déjà). Ce qui veut bien dire que vous devez avoir un compte officiel sur l'application Web 2.0 à laquelle vous souhaitez vous connecter. Suite à l'autorisation que vous donnez, vous devriez avoir en retour un code de vérification (Verifier Code en anglais).
• Etape 4 : Ce code doit être fourni sur une 3ème URL de l'application Web 2.0 en passant aussi en paramètre le Request Token. Si tout est ok, vous devriez avoir en retour un jeton d'accès et un mot de passe associé définitifs à l'application Web 2.0. Vous pouvez alors les enregistrer pour l'utilisateur spécifique qui a donné son accord. Ils seront nécessaires à chaque fois que vous souhaiterez effectuer une action spécifique (recherche, création, modification, ...) sur l'application Web 2.0 à partir de votre propre application.

Dans un prochain billet, je vous donnerais plus de détails sur comment mettre en pratique ce type d'autorisation dans votre application. Certains développeurs ont mis à disposition en open source leur développement Java pour faciliter le développement de l'OAuth. Je citerais, par exemple, Scribe qui est une API Java qui permet de mettre en œuvre OAuth pour plusieurs applications Web 2.0 telles que Twitter, Yammer, Facebook, Google, ...