Comment déléguer ses droits utilisateur à un widget ou à une application sans lui fournir explicitement ses identifiants de connexion ? C’est la problématique à laquelle ont souhaité répondre les concepteurs de OAuth.
OAuth 2 est un framework / protocole d’authentification pensé pour minimiser les échanges d’informations confidentielles, donc.
Parmi les cas d’usage les plus courants, on retrouve l’accès à une API externe et la connexion à un site via l’authentification sur un site tiers.
Voici un petit exemple fictif illustrant l’intérêt de OAuth 2 :
Accès à une API externe
Trois parties sont à considérer :
Le fournisseur de données : disons Instagram. Site sur lequel il faut créer un compte pour profiter pleinement de l’expérience utilisateur.
Un utilisateur lambda d’Instagram : Disons vous, cher lecteur.
Une application en ligne : imaginons une application qui propose d’aller liker à votre place toutes les photos ayant le hashtag de votre choix.
Quand on arrive sur l’application, celle-ci a besoin d’interagir avec l’API en votre nom, pour pouvoir liker les photos à votre place. On pourrait alors imaginer une solution où l’on donne tout simplement son identifiant et son mot de passe Instagram à l’application pour qu’elle se connecte à notre place.
Je ne sais pas vous, mais moi je suis pas du genre à donner mes identifiants de connexion Instagram à la première personne venue. Encore moins à une application en ligne. C’est là que OAuth 2 intervient : l’idée est tout simplement d’avoir un système où l’utilisateur peut déléguer ses droits à une application tierce sans jamais lui donner ses identifiants.
Tout repose sur le principe du jeton (token en anglais) : l’application récupère un token, matérialisé par une chaîne de caractères unique, qui lui permet d’accéder à la plateforme pendant un temps limité.
Comprendre les différents schémas d’obtention d’un token
Vous avez encore un peu de mal à visualiser la manière dont les tokens sont donnés, renouvelés et comment tout cela fonctionne ? Hé bien, je ne vais pas vous l’expliquer, car d’autres l’ont très bien fait avant moi 🙂
Avant de vous renvoyer vers des ressources externes, j’ai quand même envie de résumer en quelques mots les types d’authentification les plus courants en reprenant notre exemple d’application Instagram fictive :
Authentification explicite
- L’application s’est préalablement enregistrée auprès d’Instagram et a obtenu son client id
- Vous, l’internaute, arrivez sur l’application « I like for you »
- L’application vous redirige sur l’espace d’authentification d’Instagram, communiquant au passage son Client ID
- Vous vous identifiez et autorisez l’application à accéder à votre compte
- Instagram redirige vers l’URL définie par l’application avec un code en paramètre d’URL
- Le serveur de l’application récupère ce code et va s’en servir pour demander son token auprès d’Instagram
- Instagram renvoie au serveur le token
Et voilà ! Vous n’avez pas divulgué vos identifiants à l’application et en plus le token ne passe jamais côté navigateur
Authentification implicite
Même principe mais une étape en moins, le token étant directement communiqué au navigateur, en lieu et place du code intermédiaire.
- L’application s’est préalablement enregistrée auprès d’Instagram et a obtenu son client id
- Vous, l’internaute, arrivez sur l’application « I like for you »
- L’application vous redirige sur l’espace d’authentification d’Instagram, communiquant au passage son client id
- Vous vous identifiez et autorisez l’application à accéder à votre compte
- Instagram redirige vers l’URL définie par l’application avec le token en paramètre d’URL
- L’application côté client récupère ce token et peut donc requêter l’API.
C’est un peu moins secure puisque le token arrive jusqu’à votre navigateur et peut don cêtre plus facilement intercepté. Mais c’est super pratique. Ce schéma est notamment utilisé par Facebook Login.
Client Credentials Grant
Cette fois-ci, c’est simple et efficace : l’application s’authentifie directement avec un login et mot de passe. L’utilisateur n’intervient donc plus, c’est l’application elle-même qui possède son propre jeu d’identifiants. Cela signifie que cette dernière n’a pas besoin de droits supplémentaires à réclamer à l’utilisateur final (s’il y en a un) mais permet au service qui fournit les données de savoir à quelle application elle les fournit.
Ressources
Il y a encore pas mal de choses à voir. J’ai volontairement omis de vous parler de la récupération d’un nouveau token d’accès grâce au token de rafraîchissement, par exemple. Voici trois articles expliquant plus en détail le schéma de chaque scénario, les différentes implications techniques et les potentielles failles de sécurité de chaque méthode.
Il y a cet article : Comprendre OAuth 2 par l’exemple – Très clair et complet
Il y a également celui-ci : OAuth 2 logging with facebook – Moins technique, plus conceptuel, néanmoins intéressant
Ou encore celui-là : Comprendre OAuth 2. – Très proche du premier article, les failles y sont plus explicitées et illustrées par l’exemple