OAuth est né de la volonté d’offrir une solution simple et sécurisée aux mécanismes d’autorisation 3 parties. D’une part le client qui représente l’application qui veut utiliser mes données, d’autre part le serveur qui possède les données en question et enfin l’utilisateur qui valide ou non l’accès à ses données.
En effet les différents services web sont de plus en plus interconnectés, par le biais d’API, et il n’est pas rare qu’en tant qu’utilisateur je veuille donner la permission à l’application X d’utiliser certaines de mes données de l’application Y.
Avant OAuth, pour y parvenir, je n’avais pas beaucoup de solutions. J’étais généralement obligé de livrer mon login / mot de passe de Y à X.
Ils sont partout, souvent sans que l’on s’en rende compte. Par exemple lorsque j’utilise un client twitter sur smartphone ou sur ordinateur, à chaque fois que je veux poster un message l’application ne me demande pas mon mot de passe.
L’application en question a simplement eu besoin que je l’autorise à un moment donné, mes identifiants ne sont pas transmis à chaque requête.
Comme le montre la capture, je peux à tout moment révoquer cet accès.
Le graphique de Yahoo explique bien le cheminement nécessaire pour qu’un utilisateur puisse donner accès à une ressource.
Voici le déroulement du processus:
Il y a donc 3 types de jetons:
Le cheminement pour l’utilisateur est donc relativement simple, le service qui demande à accéder aux ressources (client) redirige vers le service qui propose la ressource (serveur) en spécifiant un callback.
Une fois l’accès validé par l’utilisateur, le service de destination (serveur) redirige vers le service demandeur (client) grâce au callback.
Une fois ce processus terminé le client peut agir au nom de l’utilisateur.
Il faut noter que les jetons constituent un accès temporaire et n’ont pas vocation à être utilisables ad vitam æternam.
La RFC propose deux méthodes pour signer les requêtes:
Il ne faut pas confondre authentification et autorisation. OAuth est un mécanisme d’autorisation là ou openid se veut un mécanisme d’authentification. Le premier vise à autoriser là ou le second vise à identifier une personne.
Il est important de noter que OAuth ne propose pas de mécanisme granulaire d’autorisation à proprement parler, il offre un mécanisme d’accès à un service mais ce n’est pas lui qui détermine à quoi a accès X. En fait, libre à Y d’implémenter ce mécanisme et de définir quelles seront les données accessibles.
En terme de sécurité, les différents mécanismes mis en place souffrent de quelques faiblesses:
S’il y a une gem à avoir dans sa trousse à outil du bon développeur ruby, c’est omniauth qui s’intègre avec un nombre incroyable de services.
Cette gem est très bien maintenue et testée.
OAuth est maintenant un protocole largement répandu et s’est imposé comme la référence. A ce jour il parait impensable de ne pas l’utiliser si vous souhaitez construire une API avec un accès protégé.
L’équipe Synbioz.
Libres d’être ensemble.
