OAuth.io est une API et un service s'interfaçant avec plus de 80 fournisseurs OAuth. Cet article rapporte un entretien avec Mehdi Medjaoui, cofondateur d'OAuth.io, dans lequel sont abordés les sujets de la sécurité, du mode de licensing et des développements à venir. OAuth.io a pour intention de simplifier l'écriture de code pour les autorisations des utilisateurs et des APIs. Plutôt que d'avoir à composer avec de multiples fournisseurs OAuth, qui peuvent chacun implémenter différentes versions du protocole (1.0, 1.0a, 2.0), le développeur peut programmer en utilisant une API unique, comme le montre l'extrait suivant :
$('#fb-connect').click(function() {
OAuth.initialize('YOUR_PUBLIC_KEY');
OAuth.popup('facebook', function(err, res) {
if (err) {
// do something with error
alert(JSON.stringify(err));
return;
}
$('#token').html(res.access_token)
.parent().show();
});
});
OAuth.io supporte plus de 80 fournisseurs OAuth dont Facebook, Twitter, Google (différents services), GitHub, Flickr, LinkedIn, Dropbox, etc. et l'équipe derrière le projet reste ouverte aux suggestions concernant quels autres fournisseurs supporter dans le futur. L'API est accessible en tant que service gratuit ou payant ou en exécutant le service sur sa propre infrastructure.
InfoQ a discuté avec Mehdi Medjaoui, cofondateur de OAuth.io pour en savoir plus sur cette API et le service qui l'accompagne.
InfoQ : OAuth.io est-il encore en beta ? Si oui, quand pensez-vous qu'il sera disponible ?
MM : Le service est d'ores et déjà fait pour des applications de production. Notre plus important utilisateur en production intègre 12 fournisseurs OAuth dans la même application avec OAuth.io. Nous avons actuellement plus de 1380 applications l'utilisant, 84 en production, et ce, 5 semaines après le lancement.
Toutefois, un grand nombre de fonctionnalités est à venir dans les prochaines semaines et nous avons encore besoin de valider la stack de services sur des centaines de milliers, voire des millions d'applications d'utilisateurs, c'est pourquoi nous gardons le label beta.
InfoQ : si je comprends bien, un utilisateur qui souhaite utiliser l'authentification via OAuth.io le fait à travers oauthd, un démon s'exécutant sur Amazon, n'est-ce-pas ? Pourriez-nous nous expliquer l'ensemble du processus ?
MM : OAuth.io est à l'heure actuelle une API pour plus de 80 fournisseurs OAuth. En fait, OAuth.io est une version hébergée de oauthd, le démon OAuth open source que nous développons. Le service OAuth.io s'exécute sur Amazon EC2 et propose aux développeurs une interface Web simple, facile d'utilisation, pour configurer et consommer leurs divers fournisseurs OAuth de façon unifiée. Que fait OAuth.io ? L'application cliente appelle OAuth.popup ou OAuth.redirect en JavaScript. Elle fait une requête à OAuth.io en précisant le provider auquel se connecter. Ensuite, OAuth.io informe l'application qu'il faut ouvrir une popup ou rediriger vers le formulaire d'authentification du provider. Une fois authentifié, le provider redirige vers OAuth.io, qui fera la demande du token et le renverra à la fonction de callback JavaScript.
Dans le cas d'un échange initié côté-serveur, l'application cliente reçoit simplement un code, à envoyer au serveur via une requête Ajax. Le serveur requête OAuth.io avec sa clef secrète afin d'échanger le code contre le token.
InfoQ : Actuellement, il existe un inconvénient majeur, lié à la sécurité : vous stockez les clefs privées des utilisateurs. Que prévoyez-vous de faire à ce sujet ?
MM : La sécurité est notre plus haute priorité dans notre mission qui vise à résoudre la question de l'intégration d'OAuth pour les développeurs. La sécurité, tout comme la performance et l'expérience utilisateur.
OAuth.io est un Backend-as-a-Service (BaaS) OAuth pour vos applications, c'est pourquoi nous demandons les clefs des APIs de vos applications, comme le font tous les Backend-as-a-Services. Voici comment nous gérons la sécurité avec OAuth.io :
- Tout est chiffré avec SSL EV, afin de sécuriser la communication entre OAuth.io et l'utilisateur.
- Le code envoyé est à usage unique et avec une date d'expiration très courte, pour s'assurer qu'une personne extérieure ne puisse pas le réutiliser.
- La validité des domaines et urls dépend du niveau le plus détaillé : il est possible de restreindre à un seul scheme/domain/port/path, de sorte que la redirection ne peut pas être trompée pour faire fuiter un jeton d'accès.
- Le paramètre "state" est à présent obligatoire lors des autorisations côté-serveur, afin d'éviter les attaques CSRF.
- Le mode client-side ou server-side (token ou code) est décidé dans la configuration de l'application, et pas dans la requête ; si bien qu'obtenir un jeton ne se résume pas à changer un paramètre dans une requête.
- Nous ne stockons aucun access_token, afin d'assurer la sécurité dans les pires scénarios d'attaque.
- Nous avons évité les fuites de fragments d'URLs (récupérer un access_token d'un referrer), à cause de hacks récents de Facebook.
- Nous avons vérifié un grand nombre de failles de sécurité potentielles de type CSRF/XSS et ce que nous avons réalisé avec Angular.js a passé tous les tests avec succès.
- Enfin, globalement, le site Web est basé sur des APIs. Ainsi, il est plus facile de maîtriser les aspects liés à la sécurité.
Pour être complètement transparents auprès des utilisateurs qui veulent héberger leurs APIkeys, le code est open source et ils peuvent installer la version open source du démon, oauthd, accessible sur Github https://github.com/oauth-io/oauthd.
InfoQ : Si quelqu'un veut tout avoir sous contrôle et exécuter oauthd sur ses propres serveurs, il a votre autorisation d'utiliser oauthd, n'est-ce pas ? Pouvez-vous nous dire quelques mots sur les conditions de licensing ?
MM : Oui, oauthd est open source, sous licence Affero GPL, la "licence GPL pour les technologies serveurs", comme l'est MongoDB par exemple.
C'est une licence relativement nouvelle, c'est pourquoi nous devons expliquer qu'avec AGPL, le copyleft ne s'applique pas à l'ensemble du projet mais qu'aux modifications apportées à oauthd.
Parce que oauthd est une application autonome exécutée en tant que démon, il suffit aux utilisateurs de redistribuer à la communauté les modifications qu'ils ont faites à oauthd sous la même licence open source, et NON PAS tout le code du projet comme avec les autres licences GPL classiques.
Ceci signifie que :
- Tous les projets open source peuvent utiliser oauthd pour leurs applications et projets.
- Les projets non-open source utilisant oauthd en tant que serveur stand-alone ne doivent redistribuer à la communauté que les modifications apportées à oauthd (et NON la totalité du projet).
Nous proposons une licence commerciale aux sociétés intéressées par avoir oauthd sur leurs serveurs et souhaitant garder privées les modifications qu'elles ont faites à oauthd ou à leur code lié à oauthd. Le prix de la licence commerciale dépend du service de support requis.
Pour bien se faire comprendre au sujet d'AGPL : Notre objectif en utilisant AGPL est de préserver le concept de copyleft pour oauthd. Avec la traditionnelle GPL, le copyleft est associé au concept de distribution du logiciel. Le problème, c'est que de nos jours, avec la tendance à exécuter dans le Cloud, la distribution de logiciel se fait rare. AGPL corrige ce manque en disant que si vous utilisez le logiciel à travers un réseau, vous êtes liés par copyleft. Ce point mis à part, la licence est la même que GPL v3.
InfoQ : Qu'avez-vous prévu sur votre Roadmap ? Prévoyez-vous de supporter plus de langages, autres que JavaScript ?
MM : Oui, en effet. Notre prochaine étape est de se positionner sur le mobile avec les SDKs pour iOS, Android et BlackBerry. Nous avons reçu des centaines d'emails nous demandant d'être présents sur les mobiles, avant la question des autres langages. Nous espérons lancer ces SDKs début septembre. Ensuite, nous travaillerons sur les SDKs Python, Ruby, PHP, .NET et Java, d'ici la fin de l'année.