J'étais déjà passablement irrité par un commentaire de Sam Ruby, mais lorsque je lis de telles énormités je me sens obligé de réagir. Je ne vais pas énumérer point par point les incohérences déjà décrites par Stuart Dallas dans les commentaires mais plutôt essayer d'expliquer le plus simplement possible de quoi on parle.
[edit] : English readers, take a look at this excellent translation from Karl Dubost.
OpenID
Prenons le cas concret d'un blog. Lorsque vous utilisez OpenID, vous prouvez uniquement que la personne qui a laissé un commentaire avec une adresse donnée sera toujours la même. Il n'y a aucune notion de certification m'assurant que cette adresse correspond à une personne donnée (à part peut-être pour les geeks qui font de la délégation). Je peux très bien créer demain rantanplan.myopenid.net et me faire passer pour Rantanplan sans être Rantanplan donc cette problématique n'est pas résolue par OpenID (du moins pour l'instant).
OAuth
OAuth permet uniquement de gérer plus finement les accès à ses données sur un service. Ça laisse un plus grand contrôle mais n'augmente en aucun cas la sécurité. Si vous laissez accès à toutes vos données (et personne ne lit ces pages donc ça sera très facile, sinon personne ne laisserait son login/pass à un service tiers), on revient exactement au même problème, que ce soit Twitter ou autre.
Le seul vrai avantage d'OAuth est de permettre de supprimer des accès via le service contenant mes données. Par exemple pour Twitter, j'ai laissé Saloon2.0 accéder à mes billets, le service est racheté par LesDaltons, je peux supprimer le token d'accès via Twitter sans que les autres services utilisant mes données Twitter ne soient impactés (ce qui n'aurait pas été le cas si j'avais dû changer mon mot de passe utilisateur).
Le véritable contrôle de ses données et de son identité commence par l'éducation des utilisateurs, leur faire prendre conscience des problèmes et expliquer les solutions possibles. OpenID et OAuth ne sont pas des solutions miracles et il faut être conscient de leurs faiblesses et limitations pour pouvoir les utiliser à bon escient et communiquer efficacement sans énoncer des choses fausses à leur sujet.
Aller plus loin
- Twitter and the Password Anti-Pattern
- OAuth, Phishing, and Twitter
- OAuth and Twitter: Realistic expectations (découvert après la rédaction de ce billet en voulant faire un lien dans l'intro, dommage ça m'aurait épargné de la salive numérique ;-))
10 Commentaires
Tu devrais nous écrire tout ça... en anglais.
Parce que c'est juste essentiel ce que tu dis là.
1 | NiKo, le 26 January 2009 à 07h
Je vais le traduire aujourd'hui sauf si David me dit qu'il l'a déjà fait.
2 | karl Dubost, le 26 January 2009 à 12h
"Il n'y a aucune notion de certification m'assurant que cette adresse correspond à une personne donnée [...] cette problématique n'est pas résolue par OpenID (du moins pour l'instant)."
Pour y arriver, il faudrait une vérification d'identité ET faire confiance au fournisseur OpenID dans cette vérification d'identité. Pour en arriver là, le plus simple est de jeter OpenID à la poubelle et faire une bonne vieille authentification par certificat :D
"OAuth permet uniquement de gérer plus finement les accès à ses données sur un service."
Wo l'aut', il essaie de nous faire croire que la gestion des autorisations est normalisée dans OAuth :-)
3 | Damien B, le 26 January 2009 à 13h
@NiKo : mon niveau d'anglais m'interdit toute forme de publication sérieuse dans cette langue malheureusement... (et puis le but de ce blog c'était aussi de pouvoir communiquer en français sur ce genre de problématiques).
@Karl Dubost : je ne l'ai pas traduit, par contre c'est vrai qu'il y a quelques inexactitudes concernant la sécurité et OAuth, comme nous en discutons sur http://lists.w3.org/Archives/Public/public-social-web-talk/ (mais tu dois être au courant ;-)).
Ma conclusion c'est qu'il y a en effet un gain au niveau sécurité en théorie mais dans les faits ce n'est malheureusement pas le cas (en tout cas pour l'instant).
@Damien B : ah, tes commentaires me manquaient !
> il faudrait une vérification d'identité ET faire confiance au fournisseur OpenID dans cette vérification d'identité
Tout à fait, après peut-on faire confiance à des fournisseurs comme l'état ou les communes par exemple ? (ça va dépendre des pays, etc bien sûr)
La méthode des certificats est intéressante (et je suis de près ce qui se fait avec FOAF+SSL) mais ça reste très geek. Est-ce que les clés PGP ont une chance d'arriver à percer, je ne pense pas et c'est un peu la même chose là... enfin ça dépend de l'évolution des navigateurs en parallèle aussi.
> il essaie de nous faire croire que la gestion des autorisations est normalisée dans OAuth
En effet, ça dépend de l'implémentation que l'on en fait, d'où le nombre d'extensions qui fleurissent pour spécifier quelles ressources sont concernées, etc. Note que c'est un peu mieux précisé dans la spec IETF:
http://oauth.googlecode.com/svn/spec/core/IETF/drafts/1/draft-hammer-oauth-00.txt
o The Service Provider presents to the User information about the
Consumer requesting access (as registered by the Consumer
Developer). The information includes the duration of the access
and the Protected Resources provided. The information MAY include
other details specific to the Service Provider.
Mais ça reste bien flou :-)
4 | David, biologeek, le 26 January 2009 à 14h
Merci beaucoup David, je vais mettre à jour mon dossier sur l'identité numérique ;-) .
Par contre, je vois mal l'état ou les communes comme Provider ou même une initiative permettant de certifier une identité… Une bonne alternative serait les FAI, qui eux ont au moins la certitude qu'on est la personne qu'on prétend être (ils ont des coordonnées bancaires et postales quand même). Mais ça pose d'autres problématiques…
Par contre pour OAuth, en quoi ce n'est pas si sécurisé que ça ? Parce que les consumers ne précisent pas les données qu'ils vont utiliser ?
5 | Neovov, le 26 January 2009 à 14h
Et voila, tu peux en faire ce que tu veux :)
http://www.la-grange.net/2009/01/26/openid-oauth
6 | karl Dubost, le 26 January 2009 à 17h
@David
"Est-ce que les clés PGP ont une chance d'arriver à percer"
Non, c'est du décentralisé :)
"Note que c'est un peu mieux précisé dans la spec IETF"
"draft-00.txt", ah ouais, ça fouette :) "The information MAY include other details " : oh, c'est précis comme une spécification de µFormat.
7 | Damien B, le 27 January 2009 à 13h
@Neovov : oui les deux autres entités que je vois qui pourraient avoir un rôle à jouer sont les banques et les fai, mais ça pose d'autres problèmes et je ne vois pas pourquoi l'état, qui nous représente déjà, ne pourrait pas certifier notre statut de citoyen du net (en théorie en tout cas, après vu l'inertie c'est pas près d'arriver...).
> Par contre pour OAuth, en quoi ce n'est pas si sécurisé que ça ? Parce que les consumers ne précisent pas les données qu'ils vont utiliser ?
Comme le soulignait Damien, la spec est très imprécise à ce niveau, le service provider peut faire ce qu'il veut : d'un gros bouton qui signifie "Donner toutes mes données en lecture/écriture à untel" à une gestion beaucoup plus fine par ressource. Bon en 1.0, tu n'as pas la possibilité non plus de spécifier en tant que consumer à quelles ressources est-ce que tu veux accéder (du moins de manière standard) ce qui est clairement limitant...
Maintenant sur la sécurité, il y a du bon et du moins bon. En fait, ça dépend pas mal du niveau des utilisateurs de ton appli. S'ils savent détecter un hameçonnage (phishing), alors OAuth est vraiment mieux. Sinon ça laisse toujours ta porte grande ouverte (comme l'était la demande de login/pass) mais tes fenêtre sont mieux renforcées (youpi).
@karl Dubost : merci ! Bon je sais pas quoi en faire du coup :p
Soit je la met à la suite du billet actuel, soit je fais un lien vers la-grange, ce que j'ai commencé à faire, mais il va falloir nettoyer un poil plus le html (au moins le title et les liens).
@Damien B : En même temps il faut reconnaître que c'est pas évident à spécifier non plus si tu veux rester assez générique.</avocatdudiable>
8 | David, biologeek, le 27 January 2009 à 18h
De mon point de vue l'avantage qu'apporte la "méthode" d'authentification Oauth en terme de sécurité est qu'elle certifie à l'utilisateur que ses identifiants permettant de se connecter au service auquel il souhaite accéder ne pourront pas être interceptés par l'application tierce à partir de laquelle il agit.
9 | Clément, le 5 February 2009 à 17h
Tu veux pas donner ton mot de passe et ton login à un service tiers mais tu veux bien faire certifier ton identité sur le net par l'état... J'ai l'impression que cela va donner lieu à divers vagues problèmes sur la vie privée mais bon.
merci encore pour tous ces postes qui me rassure.
10 | akaj, le 9 March 2009 à 18h
Ajouter un commentaire