Nous avons déjà évoqué les cas où l’on nous demande de révéler un mot de passe et l’impératif de ne jamais y répondre. Lorsqu’un site Web souhaite utiliser les services d’un autre – par exemple lorsque Bitly s’applique à publier sur votre fil Twitter –, la bonne façon de procéder n’est pas de vous demander de le saisir, mais d’utiliser OAuth.
OAuth est un protocole d’authentification qui vous permet d’approuver un dialogue entre deux applications pour votre compte sans pour autant révéler votre mot de passe.
Nous vous proposons le mémento ci-dessous pour illustrer, dans la plus grande simplicité, comment fonctionne OAuth.
Les acteurs
Dans toute transaction OAuth, on trouve 3 acteurs principaux : l’utilisateur, le consommateur et le fournisseur de service. Ce trio est parfois désigné du sobriquet plaisant de « Triangle amoureux OAuth » (“OAuth Love Triangle”).
Dans notre exemple, Joe désigne l’utilisateur, Bitly est le consommateur et Twitter est le fournisseur de service qui gère le contenu sécurisé de Joe (son flux Twitter). Joe souhaite que Bitly puisse poster des liens raccourcis dans son flux. Voici comment se déroule le processus :
Étape 1 – L’utilisateur manifeste son intention
Joe (Utilisateur) : « Hé, Bitly, j’aimerais que tu puisses poster des liens directement dans mon flux Twitter. »
Bitly (Consommateur) : « Très bien ! Attends que j’en demande la permission. »
Étape 2 – Le consommateur obtient la permission
Bitly : « J’ai un utilisateur qui aimerait que je puisse poster dans son flux. Est-ce que je pourrais avoir un jeton de demande ? »
Twitter (Fournisseur de service) : « Pas de problème. Voici un jeton et un secret. »
Le secret sert à éviter les demandes illicites. Le consommateur « signe » chacune de ses demandes à l’aide du secret, de sorte que le fournisseur de service puisse s’assurer que la demande émane bien de l’application consommatrice.
Étape 3 – L’utilisateur est redirigé vers le fournisseur de service
Bitly : « OK, Joe, je te transfère chez Twitter pour que tu puisses valider la demande. Pour cela, utilise ce jeton. »
Joe : « OK ! »
<Bitly transfère Joe sur Twitter pour autorisation>
Remarque : C’est là où le risque existe : si Bitly était en réalité un grand méchant pirate, il pourrait ouvrir une fenêtre ressemblant comme deux gouttes d’eau à la fenêtre de connexion de Twitter pour « pécher » (“phishing”) votre nom d’utilisateur et votre mot de passe. Veillez toujours à vérifier que l’URL de la fenêtre vers laquelle vous êtes dirigé est bien celui du fournisseur de service (Twitter dans notre exemple).
Étape 4 – L’utilisateur donne sa permission
Joe : « Twitter, je souhaite autoriser ce jeton de demande que Bitly m’a fourni. »
Twitter : « OK, juste pour confirmation : tu veux bien autoriser Bitly à faire X, Y et Z sur ton compte Twitter, c’est ça ? »
Joe : « Oui ! »
Twitter: « Très bien, alors tu peux retourner vers Bitly et lui dire qu’il a la permission de se servir de son jeton de demande. »
Twitter marque le jeton de demande de la mention « Valide », de sorte que lorsque le consommateur requerra l’accès correspondant, il lui sera accordé (dans la mesure où il l’aura signée à l’aide du secret partagé).
Étape 5 – Le consommateur obtient un jeton d’accès
Bitly : « Twitter, est-ce que tu peux m’échanger ce jeton de demande contre un jeton d’accès ? »
Twitter (Fournisseur de service) : « Pas de problème. Voici ton jeton d’accès avec le secret correspondant. »
Étape 6 – Le consommateur accède à la ressource protégée
Bitly : « Je voudrais poster ce lien dans le flux de Joe. Voici mon jeton d’accès à cet effet. »
Twitter : « Très bien : c’est fait ! »
Résumé
Dans notre exemple, Joe n’a pas eu à révéler ses identifiant et mot de passe Twitter à Bitly. Il a lui a simplement délégué un accès sécurisé grâce à OAuth. A tout moment, Joe peut se connecter à son compte Twitter, consulter la liste des accès externes qu’il autorisés et en révoquer éventuellement certains sans que cela affecte les autres. OAuth permet aussi de gérer différents niveaux d’accès. On peut par exemple conférer à Bitly le droit de publier sur son compte Twitter, mais ne donner à LinkedIn qu’un accès en lecture.
OAuth n’est pas parfait… en tout cas, pas encore !
OAuth est une solution éprouvée pour les applications sous navigateur Web et représente un vrai progrès par rapport à l’authentification HTTP classique. Mais elle comporte des limitations, notamment dans la version OAuth 1.0, qui la rendent nettement moins efficace et moins ergonomique dans le cas des applications natives et mobiles.
OAuth 2.0 est une version plus récente et mieux sécurisée du protocole qui introduit la notion de « flux » multiples pour les applis Web, mobile et de PC de bureau. Elle adopte aussi le concept d’expiration des jetons (similaire à celle des cookies), utilise SSL et atténue la complexité du point de vue des développeurs en n’exigeant plus de signature.
Autres ressources
J’espère que cela vous aura mieux familiarisé avec OAuth et que, la prochaine fois que vous verrez s’afficher une proposition du type « Connectez-vous avec votre compte Twitter », vous comprendrez mieux ce qui se déroule.
Si vous voulez en savoir encore plus sur le fonctionnement de OAuth, voici quelques liens utiles (en anglais) :
What you should do now
Below are three ways we can help you begin your journey to reducing data risk at your company:
- Schedule a demo session with us, where we can show you around, answer your questions, and help you see if Varonis is right for you.
- Download our free report and learn the risks associated with SaaS data exposure.
- Share this blog post with someone you know who'd enjoy reading it. Share it with them via email, LinkedIn, Reddit, or Facebook.
Rob Sobers
Rob Sobers est un ingénieur logiciel spécialisé dans la sécurité du Web et co-auteur du livre ''Learn Ruby the Hard Way''.
-1.png)