URL: https://linuxfr.org/users/moonz/journaux/mozilla-concurrence-openid Title: Mozilla concurrence OpenID Authors: Moonz Date: 2011年07月29日T14:35:21+02:00 License: CC By-SA Tags: mozilla, openid, authentification et browserid Score: 16 Tout le monde ici je pense a entendu parler d’[[OpenID]]. OpenID a pour objectif de résoudre ce problème : comment éviter d’avoir à retenir un grand nombre de mots de passe différents pour chaque site ? Malgré l’intensité du problème, la solution n’a jamais vraiment décollée. Les raisons incluent : 1. une méfiance des utilisateurs : puis-je confier l’accès à tous mes sites à un seul fournisseur ? 2. une méfiance de la part des sites : comment m’assurer que le serveur OpenID n’a pas été compromis ? 3. l’éternel problème du bootstraping : pourquoi prendre un OpenID puisqu’aucun site ne le propose ? pourquoi implémenter OpenID sur mon site puisque personne n’en possède ? 4. des problèmes de vie privée : dans un monde entièrement en OpenID, le fournisseur d’identité a accès à tout l’historique de navigation de ses utilisateurs 5. des problèmes d’utilisabilité : complexe à déployer pour les sites ; les utilisateurs comprennent plus facilement ce qu’est une adresse email plutôt qu’une URL Malgré qu’OpenID n’ait pas décollé, le problème reste entier. Il s’accentue même chaque jour, avec de nouveaux services qui apparaissent régulièrement, et qui demandent chacun leur propre couple login/mot de passe. Mozilla a donc décidé de lancer sa propre initiative, [BrowserID](http://identity.mozilla.com/post/7616727542/introducing-browserid-a-better-way-to-sign-in). Regardons rapidement son fonctionnement (avec test@gmail.com) : * Un BrowserID est une adresse email ; le fournisseur d’identité est soit le serveur derrière le "@" s’il suit le protocol, browserid.org prenant la main si ce n’est pas le cas. Évidemment, cette dernière situation est plus à prendre comme une mesure de transition. * L’utilisateur commence par s’identifier sur le fournisseur d’identité. Il génère ensuite une paire de clefs publique/privée. Il envoie la clef publique au fournisseur. Ce dernier génère alors un certificat disant "moi, gmail.com, certifie que la clef privee dont la clef publique associee est xxxyyy est possédée par test@gmail.com" (actuellement, ce serait plutôt "moi, browserid.org, certifie etc.") * Lorsque l’utilisateur décide ensuite de se connecter sur un site, il founit à ce dernier (via une fonction javascript) : le certificat, et la preuve qu’il détient bien la clef privée associée à la clef publique donnée dans le certificat. Le site vérifie alors le certificat en récuperant la clef publique du fournisseur ; si ca colle, alors on peut dire que l’utilisateur du browser possède bien l’adresse test@gmail.com Alors, relativement aux soucis posés par OpenID, comment se positionne ce concurrent ? 1. Méfiance des utilisateurs et des sites : rien de neuf sous le soleil. 2. Bootstraping : problème à moitié résolu ; tout utilisateur possédant une adresse email possède un BrowserID. L’autre moitié (les sites) est toujours problématique, toutefois. 3. Vie privée et utilisabilité : sur ces deux points, BrowserID surclasse OpenID. Le fournisseur BrowserID n’a pas connaissance de l’historique de navigation de ses utilisateurs ; tout ce qu’il voit, c’est « monsite.com m’a demandé ma clé publique, sûrement pour vérifier le certificat d’un de mes nombreux utilisateurs qui veut se connecter sur ce site ». L’API côté site est simple, et pour l’utilisateur, c’est aussi simple que de rentrer une adresse email. Autre avantage, toute l’interface utilisateur (sauf la partie : s’authentifier auprès du fournisseur BrowserID) peut être directement implémentée par le navigateur, sans toutefois que ce soit nécessaire. Flexibilitée et ergonomie donc. Un inconvénient majeur est que tout ceci ne peut fonctionner sans Javascript/JSON/XHR, au contraire de OpenID. L’autre inconvénient, est que cette nouvelle solution va encore ajouter une nouvelle méthode d’authentification, en plus de Facebook, Google (qui derrière utilisent OpenID, d’ailleurs) et quelques autres. Les webmasters accepteront-ils d’alourdir une page déjà longue comme un bras pour une simple authentification ? J’en doute. BrowserID remplacera-t-il GMail ou Facebook sur cette page ? J’en doute. Bref : ceux qui supportent déjà OpenID auront une raison ergonomique de ne pas ajouter BrowserID. La simplicité de l’API arrivera-t-elle à faire basculer ceux qui n’avaient pas encore commencé à supporter OpenID, encourageant les premiers à trouver un peu de place dans leurs méthodes d’authentification ? L’avenir le dira. Souhaitons leur en tout cas bonne chance, que ce problème des multiples mots de passe soit enfin (et proprement) résolu.

AltStyle によって変換されたページ (->オリジナル) /