Discussion :

[tarikbenmerar]

Le protocole libre OAuth 2.0 est-il un échec ?
L'auteur en chef de sa spécification démissionne et en retire son nom


« J'ai échoué. Nous avons échoué ». C'est avec un tel fatalisme et une telle amertume qu'annonce Eran Hammer sa démission de son poste d'auteur en chef de la spécification OAuth 2.0. Il quitte le groupe de travail du protocole libre d'authentification, et retire son nom de la spécification après avoir travaillé 3 ans sur son élaboration.

Dans son blog, il explique que sa décision n'a pas été facile à prendre : « Enlever mon nom d'un document que j'ai tant bien que mal élaboré pendant trois ans, avec plus d'une vingtaine de drafts, n'était pas simple. Décider de jeter l'éponge à un effort que j'ai conduit pendant plus de cinq ans était agonisant. »

Mais face à la situation régnante, sa décision était imminente : « OAuth 2.0 est un mauvais protocole. Un mauvais WS-*. Il est mauvais au point où je ne veux plus y être impliqué. C'est la plus grande déception professionnelle de ma carrière », reconnaît-il. Avant d'ajouter que tous les compromis qui ont été faits ont eu pour résultat « une spécification qui a échoué à atteindre ses deux principaux objectifs – la sécurité et l’interopérabilité ».

Selon Hammer, le cœur du problème est le conflit incessant entre la culture du Web et celle de l'entreprise. Au début, le groupe de travail de OAuth à l'IETF (Internet Engineering Task Force) était caractérisé par une forte présence [des acteurs] du web. Mais, après la première année, tous les membres de la première spécification ont quitté le groupe. « Le groupe restant était essentiellement composé d'entreprises.... et de moi-même ».

Au-delà des problèmes organisationnels internes, Hammer explique que des changements architecturaux ont introduit des complexités inutiles, pour résoudre des problèmes mineurs. Ce serait par exemple le cas de la révocation des tokens dans la première spécification, remplacée par les tokens illimités.

Il accuse aussi la spécification de manque cruel en détails et en... spécifications. Elle laisse selon lui beaucoup trop de choix aux implémentations avec pour résultat, un manque flagrant d’interopérabilité.

Notons que techniquement parlant, Hammer estime qu'il est préférable de rester sur la version 1.0 pour ceux qui l'utilisent sans encombre. Pour les autres qui se considèrent comme experts en sécurité, une analyse approfondie des fonctionnalités de la 2.0 serait primordiale, à moins d'utiliser une implémentation sûre de la version 2.0 (comme celle de Facebook). « La 2.0 est meilleure pour un déploiement d'une grande infrastructure » - conclut-il.



Source : le blog de Eran Hammer

Et vous ?

Utilisez-vous le protocole OAuth 2.0 ?
Partagez-vous les critiques qu'assène Hammer à sa spécification ?

[cisco]

j'utilise le protocole oauth et le connait bien puisque nous faisons la partie serveur et la partie cliente (enfin surtout serveur, parce que la partie cliente se résume à utiliser une librairie genre signpost)

J'ai migré mon implémentation de oauth 1 vers oauth 1a, et étudie la possibilité donner la possibilité d'être compatible oauth2.

Pour info (et parce que le blog n'en parle pas) google est aussi sous auth 1 et 2. Leur implémentation est décrite ici:
https://developers.google.com/accounts/docs/OAuth2

Et effectivement la première implémentation que j'ai faite était 'naïve' dans le sens ou le rfc est quand même compliqué et nous avons loupé des trucs comme le rafraîchissement (et la réutilisation) des token. C'était une faiblesse d'un point de vue sécurité, et cette implémentation a été un moment en production

Autrement ce protocole reste pour moi incontournable si on fait des sites qui soit accessible par plusieurs type de client, spécialement des client 'mobile' (android ou autre), mais par exemple nous enrichissons la specification en proposant des API pour retrouver un token d’accès sans avoir à faire de redirect

J'ai quand même un gros doute non pas sur la sécurité du protocole, mais sur la vision qu'on les utilisateurs sur les applications qui utilisent ce protocole.

Voici mon souci: Il est très confortable d'essayer une nouvelle application sans faire de demande d'inscription à cette application, en utilisant son compter google ou facebook. On clique sur le boutons 'se connecter avec google', et on se retrouve avec des écran google que l'on connait bien, et qui nous demande si on est ok pour autoriser une application à se connecter sur notre compte. Le problème est que on a eu un contrat assez clair sur l'utilisation de nos données par google ou facebook, mais rien avec cette application qui peut littéralement voler nos données, et peut vraiment faire ce qu'elle veut, genre recoupage des donnés entre facebook et google ou toute autre genre de truc qu'on aurai jamais autorisé.

Pour ceux qui ne vois pas de quoi je parle, voici la version gentille de google sur auth 2. Regarder les information qu'elle vous 'vole' par rapport au écran d'acceptance
https://oauth2-login-demo.appspot.com/profile

Vous voyez que vous ne signez rien sur l'utilisation de vos données. Plus qu'à espérer que l'application ne soit pas trop crapuleuse...

[esion]

... sauf que twitter ne supporte pas oauth2

Bref, en effet l'implémentation de oauth2 me paraissait étrangement complexe et je me disais que ça venait des librairies que j'utilise .. ou pas.
Mais si effectivement le protocole n'est pas secure; autant penser à faire un retour en arrière comme d'autres l'ont osé pour d'autres raisons (php6).

En tout ça donne vraiment une mauvaise image du protocole si l'auteur abandonne aussi lâchement son bébé.

[zeyr2mejetrem]

En tout ça donne vraiment une mauvaise image du protocole si l'auteur abandonne aussi lâchement son bébé.

Je trouve pas du tout que l'auteur fait preuve de lâcheté.
Je pense au contraire qu'il faut un certain courage pour avouer publiquement que le résultat de 3 ans de travail n'est pas à la hauteur et qu'on s'est planté sur toute la ligne.

Un abandon lâche aurait été de s'effacer discrètement en disant un truc du genre "Je suis appelé à d'autres tâches et n'aurai plus le temps de me consacrer à ce document donc je laisse la place à d'autre" puis d'attendre au chaud que le bouzin soit enterré.

[esion]

Hmmoui j'aurai dû dire "...l'auteur abandonne aussi sèchement son bébé".

En fait j'avais l'impression en lisant l'article qu'il n'a que très peu essayé de remettre la machine sur les rails. Erreur de d’interprétation, my bad.

[zeyr2mejetrem]

Hmmoui j'aurai dû dire "...l'auteur abandonne aussi sèchement son bébé".

En fait j'avais l'impression en lisant l'article qu'il n'a que très peu essayé de remettre la machine sur les rails. Erreur de d’interprétation, my bad.

C'est clair, que ça doit faire drôle quand t'es dans un groupe de spéc et que le "boss" ou tout du moins celui qui en tient lieu se lève de réunion et dit "Bon, on fait de la merde depuis 3 ans, j'en ai marre, je plaque tout et je pars élever des poneys shetland !!"

(PS: C'est moi qui ai rajouté l'histoire des poneys car je trouvai ça marrant pas besoin de publier un démenti)

[IroS]

Voici mon souci: Il est très confortable d'essayer une nouvelle application sans faire de demande d'inscription à cette application, en utilisant son compter google ou facebook. On clique sur le boutons 'se connecter avec google', et on se retrouve avec des écran google que l'on connait bien, et qui nous demande si on est ok pour autoriser une application à se connecter sur notre compte. Le problème est que on a eu un contrat assez clair sur l'utilisation de nos données par google ou facebook, mais rien avec cette application qui peut littéralement voler nos données, et peut vraiment faire ce qu'elle veut, genre recoupage des donnés entre facebook et google ou toute autre genre de truc qu'on aurai jamais autorisé.

Pour ceux qui ne vois pas de quoi je parle, voici la version gentille de google sur auth 2. Regarder les information qu'elle vous 'vole' par rapport au écran d'acceptance
https://oauth2-login-demo.appspot.com/profile

Il ne faut pas oublier les scope. C'est au serveur d'autorisations de permettre à l'utilisateur de définir s'il autorise ou non l'accès.

The authorization server MAY fully or partially ignore the scope requested by the client based on the authorization server policy or the resource owner's instructions.

Nous avons mis en place notre API et l'accès se fait par OAuth2. Deux "filtres" ont été mis en place et différents scopes ont été établis.
Lorsqu'une application s'enregistre, elle doit saisir les scopes qui l'intéresse.
1- Si au moment de demander l'accès aux données, elles demande l'accès à des scopes non enregistrés, ceux-ci sont retirés.
2- Lorsque l'utilisateur autorise l'accès aux données, il peut retirer des scopes demandés par l'application.

Si une application A demande l'accès aux scopes user_data, user_private_data et addressbook alors qu'elle n'a demandé l'accès qu'à user_data et addressbook, user_private_data sera retiré d'office. Et ensuite, si l'utilisateur ne veut pas autoriser l'application à accéder à user_data, il n'a qu'une case à décocher.

Les seules applications pour lesquelles le 2ème filtre n'est pas possible sont les applications que nous éditons et qui ont reçues un agrément spécifique.

Je comprends la déception Eran Hammer, le protocole est très bien, mais il s'oriente vers une logique commerciale (récupération de données personnelles notamment) alors que l'idée d'origine était tout autre.
Cependant ça n'est pas le protocole en lui-même qui pose problème, mais bien la politique du serveur d'autorisations.