Mieux communiquer sur OpenID et OAuth

vignette

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

— 25/01/2009

Articles peut-être en rapport

Commentaires

NiKo le 26/01/2009 :

Tu devrais nous écrire tout ça... en anglais.

Parce que c'est juste essentiel ce que tu dis là.

karl Dubost le 26/01/2009 :

Je vais le traduire aujourd'hui sauf si David me dit qu'il l'a déjà fait.

Damien B le 26/01/2009 :

"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 :-)

David, biologeek le 26/01/2009 :

@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 :-)

Neovov le 26/01/2009 :

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 ?

karl Dubost le 26/01/2009 :

Et voila, tu peux en faire ce que tu veux :)
http://www.la-grange.net/2009/01/26/openid-oauth

Damien B le 27/01/2009 :

@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.

David, biologeek le 27/01/2009 :

@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>

Clément le 05/02/2009 :

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.

akaj le 09/03/2009 :

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.

Boboss le 11/01/2012 :

Twitter utilise exclusivement OAuth pour ses API depuis le 31 août 2010.

https://dev.twitter.com/docs/auth

=)