Une plongée dans OAuth 2

Si vous ne travaillez pas dans le développement web ou le développement de web services en Java tout dégueulasse, il est probable que vous n’ayez jamais entendu parler de OAuth. Ou bien, même si vous en avez entendu parler, il ne vous évoquera certainement rien. Je n’avais, pour ma part, jamais entendu parler de OAuth avant la semaine dernière. Et, en à peine quelques jours, j’ai fait une plongée franche dans un protocole reposant sur une idée d’une élégance rare.

Incipit

Il y a environ un mois, un membre de la communauté française de diaspora* décidait de rendre publique son travail sur une application native pour Android du réseau social. en parcourant le code, je fus interloqué par la quantité de boilerplate et de contournements qu’il avait dû mettre en place pour établir et maintenir une authentification auprès d’un pod et pour réupérer et traiter le contenu.

Il y a une semaine, alors que je finalisais mon port de l’interface de diaspora* vers Bootstrap 3 et le proposais à la communauté, je décidais alors que mon prochain travail porterait sur la création d’une API pour diaspora* afin de faciliter la communication avec des applications natives. Et la première étape de mon périple serait l’intégration d’un mécanisme d’authentification plus simple pour de telles applications. Une discussion précédente sur Loomio avait mené vers la décision d’ajouter au réseau social la possibilité de se connecter en utilisant le protocole OpenID Connect un protocole d’authentification reposant sur la spécification OAuth 2.0.

Bienheureux hasard de la vie, au début de cette semaine, mon tuteur en entreprise décidait de me déménager dans une autre équipe de développement qui, justement travaillait sur un système d’autorisation des utilisateurs reposant sur OAuth 2.0.

Histoire

L’histoire d’OpenID — ainsi que de son successeur OpenID Connect — et de OAuth sont très liés puisqu’ils se sont engendrés l’un, l’autre. Le travail sur OAuth 1.0 commence en 2006 au moment où Blaine Cook travaille sur l’intégration du protocole OpenID dans l’API de Twitter. En 2010, la RFC 5849 (en) standardise le protocole OAuth 1.0a puis, en 2012, les RFC 6749 (en) et 6750 (en) standardisent le protcole OAuth 2.0 qui devient pour l’occasion un framework — ce qui sera l’un des points de discorde puis du départ de nombreux membres du comité de spécification de la version 1.0 puis, finalement, de son créateur lui-même (en). Finalement, en 2014, OpenID Connect 1.0 succède à OpenID 2.0 et est décrit comme une surcouche d’authentification à OAuth 2.0.

Principes de base d’OAuth

OAuth, vous y avez forcément eu affaire sans le savoir. OAuth, c’est le mécanisme qui entre en jeu quand vous rencontrez le petit panneau Facebook suivant :

facebook-autorisez-vous

Bien que OAuth possède un mécanisme de vérification d’identité, il est décrit comme n’étant pas, à proprement parler, un protocole d’authentification. Il s’agit d’un protocole d’autorisation d’accès à des ressources qui repose sur la délégation de l’autorisation à une entité tierce.

Bon, comme je suspecte que cette phrase n’aide à peu près personne, voici la traduction en français :

Marie est une utilisatrice lambda de Facebook. Elle utilise ce réseau social démoniaque pour partager tout et n’importe quoi, y compris la taille de ses shorty et ses positions sexuelles préférés. Il se trouve que Marie a retrouvé sur Facebook un homme qu’elle rêverai de mettre dans son lit et de jeter au petit matin après qu’il a été chercher les croissants — elle a tout compris, cette femme ;) — et elle aimerait savoir si, niveau cul, ça va coller entre eux. Justement, il se trouve qu’il existe sur Facebook, une appli bien nommée InTheHole, proposant de mesurer la compatibilité sexuelle avec un autre membre du réseau du Malin en lisant vos données de profil — et en les revandant très cher à des sociétés d’assurance, mais ça, elle ne vous le dit pas.

Donc Marie installe l’application et Facebook lui demande de confirmer qu’elle autorise l’application à acceder à ses infos, sa photo de profil, ses contacts, ses posts, ses localisations, ses vidéos, ses déplacements, son code de carte bleue, la race de son chat, son clitoris et son âme. Marie accepte et l’application, via l’API Facebook a alors accès au passé, au présent et au futur de Marie.

Voilà, OAuth, ça permet de faire ça, ni plus ni moins. Marie fait confiance à un tiers — ici Facebook (nan mais sérieux, pour faire confiance à Facebook, faut vraiment pas être net…) — pour la gestion de l’accès a des ressources — ici, ses informations personnelles — d’une application tierce — ici une application Facebook, mais ça peut être une application Android native.

C’est ici que se profile la grande différence en OpenID Connect et OAuth : OAuth propose un mécanisme d’autorisation d’accès à des ressources mais pas d’authentification. Dans le cas présent, Facebook n’a à aucun moment vérifié l’identité de Marie puisque Marie était déjà connectée. Si Marie n’avait pas été connectée, l’application tierce aurait alors suivi le protocole OAuth et redirigé Marie vers Facebook pour qu’elle s’authentifie. Mais, à aucun moment cette application n’a besoin de se soucier de cette authentification ou du fait que Marie est bien la personne qu’elle prétend être.

Ça, c’est ce sur quoi je bosse au boulot — sans rapport avec Facebook, ceci dit, je vous rassure. Voici un petit schéma récapitulatif pour les deux-trois au fond qui son restés bloqués sur l’accès au clito de Marie :

OAuth

OpenID Connect

OpenID Connect, repose exactement sur ce mécanisme mais, cette fois pour déléguer la vérification d’une identité et non plus l’accès à des ressources. La différence, c’est le type de données qui est transmise : dans un cas, il s’agit de données quelconques, comme des données de profil mais ça peut être complètement autre chose ; dans l’autre cas, il s’agit de données représentant l’identité d’une personne. C’est le protocole qui est à l’œuvre lorsque vous utilisez les boutons :

connexion-RS

Les données transmises par OpenID Connect sont décrites très spécifiquement par le protocole mais, bien évidemment, le fournisseur d’authentification peut choisir d’ignorer ces données et de laisser les champs vides. C’est complètement laissé à la discrétion de l’application cliente et de l’application fournisseur. Dans le cas de diaspora*, par exemple, il ne nous semblera pas révélateur de transmettre une adresse ou un numéro de téléphone d’autant que l’application n’a pas ces informations. OpenID Connect repose sur OAuth pour effectuer une tâche plus précise, ce qui explique que les données transmises soient plus précises que pour OAuth. Et ça, c’est ce sur quoi je bosse pour diaspora*.

Le côté pratique de ce protcole, c’est qu’il permet d’avoir un seul compte pour se connecter partout. L’effet pervers de ça, c’est qu’il accentue la dépendance à quelques gros services comme les trois au-dessus.

L’intérêt, pour diaspora*, c’est surtout de fournir un moyen d’authentification simple pour des applications natives Android qui ne passe pas par la nécessité de remplir des formulaires web et, éventuellement, de proposer de se connecter à des services web tiers grâce à son compte diaspora*.

Déjà 4 avis pertinents dans Une plongée dans OAuth 2

  • C138
    Rien à dire de bouleversant, excepté grosse omission « pédagogique » sur la figure…
    La tête souriante au milieu, seul élément de la figure a ne pas avoir de dénomination…
    C’est qui ? un utilisateur ? Marie ? OpenID ? OAuth ?
    Et pourquoi une tête humaine ? C’est « vraiment » une personne ?

    Bonne continuation. Suite avec (petits) bout de code serait cool ;-)

  • C138
    Exercice difficile… :-P
    Même si je ne suis pas fan, passer par une représentation « à la UML » peut être plus directif… même si c’est moins agréable visuellement, c’est techniquement plus adapté/réaliste (paraît-il :-D

Laisser un commentaire

indique des champs obligatoire.