Qu’est ce que OAuth ?

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.

Les usages concrets

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 fonctionnement

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:

• Le client et le serveur doivent se mettent d’accord dans un premier temps. Pour cela des jetons clients doivent être créés. Par exemple sur twitter quand vous créez une application, vous récupérez les jetons clients (consumer key et consumer secret).
• Une fois fait, les 2 applications vont pouvoir s’échanger des jetons temporaires qui permettront de demander l’autorisation d’accès.
• Depuis l’application l’utilisateur peut maintenant être redirigé vers le serveur pour accepter ou non l’accès à ses ressources.
• Si le client valide le jeton temporaire, celui ci pourra être converti en jeton d’accès.
• Une fois le jeton enregistré, le client peut interagir avec l’API du serveur au nom de l’utilisateur jusqu’à ce que le jeton d’accès expire.

Il y a donc 3 types de jetons:

• Jetons clients (consumer): permettent d’identifier le client auprès du serveur.
• Jetons temporaires (token request): permettent d’identifier la demande d’autorisation et ne sont pas liés à un utilisateur en particulier.
• Jetons d’accès (access token): permettent d’identifier l’utilisateur.

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:

• Secret partagé (symétrique).
• RSA (asymétrique), dans ce cas la sécurité repose sur le secret de la clé privée.

Les versions

• OAuth 1.0 (octobre 2007) qui ne doit plus être utilisée en raison d’une faille de sécurité.
• OAuth 1.0a (juin 2009) qui corrige ce problème, version la plus largement répandue, utilisé par twitter, gmail, foursquare…
• OAuth 2 (mai 2010), encore en draft, utilisé par facebook.

Les confusions

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.

Les limitations

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.

Les risques

En terme de sécurité, les différents mécanismes mis en place souffrent de quelques faiblesses:

• Les redirections sont vulnérables au phishing, notamment au moment de rediriger vers le service où l’utilisateur doit entrer ses identifiants pour autoriser l’accès.
• La nécessité d’utiliser des secrets partagés expose les clés à une récupération, que ce soit par le biais d’une écoute du trafic http ou simplement dans le cas de code libre où les jetons clients seront visibles dans le code.

Les outils pour ruby

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.

Conclusion

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.