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 :
- une méfiance des utilisateurs : puis-je confier l’accès à tous mes sites à un seul fournisseur ?
- une méfiance de la part des sites : comment m’assurer que le serveur OpenID n’a pas été compromis ?
- 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 ?
- 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
- 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. 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 ?
- Méfiance des utilisateurs et des sites : rien de neuf sous le soleil.
- 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.
- 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.
# Ça vient du Web…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
On voit que ça vient de gens du Web : aucun système de choix de serveur, de redondance et de répartition. Jamais entendu parler des enregistrements SRV… Même le courrier électronique est plus moderne, avec ses enregistrements MX.
[^] # Re:Ça vient du Web…
Posté par moules . Évalué à 7.
Heu justement, si j'ai bien compris, si tu mets comme BrowserID ortolol@autohebergement.fr, le site-web va interroger le serveur autohebergement.fr pour récupérer son certificat et vérifier que le tiens a bien été signé par ce premier.
[^] # Re:Ça vient du Web…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Eh bien oui, justement. Et si je veux mettre en place mon service VerifiedMail :
eh bien je peux me brosser. Avec du courrier électronique, les points 1 et 2 sont réalisables. Avec de la messagerie instantanée, les points 1, 2 et 3 sont réalisables. Avec du Web ou du VerifiedMail, nada.
[^] # Re:Ça vient du Web…
Posté par moules . Évalué à 4.
Je n'ai pas été plus loin que le journal, mais si j'ai bien compris ce n'est encore qu'un projet dont les choix techniques n'ont pas encore été fait ?
[^] # Re: Ça vient du Web…
Posté par Jux (site web personnel) . Évalué à 2.
Euh, comme je comprends, ça utilise purement du HTTP. Donc pour la répartition de charge & co, c'est comme avec n'importe quel autre site web.
[^] # Re: Ça vient du Web…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Tout à fait, à savoir : merdique.
[^] # Re: Ça vient du Web…
Posté par Nico C. . Évalué à 1.
Hum... si y'a bien un "monde" qui connait et fait tres attention a la redondance, la repartition et les problemes de charge, c'est le web...
Tu crois que tous les sites de la terre tournent avec un simple serveur et une freebox ou bien ?
[^] # Re: Ça vient du Web…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Tu crois vraiment ? Super, alors, explique-moi comment je fais pour éviter que mon site Web devienne inaccessible si mon fournisseur d'accès déconne, par exemple.
Je mets un second serveur ailleurs ? Mais il aura une adresse IP différente…
Je mets deux enregistrements DNS A ? Mais les adresses correspondantes vont être interrogées à tout de rôle, c'est de la répartition de charge, ça, pas de la redondance. Si quelqu'un cherche à accéder à mon site Web, il aura une chance sur deux de tomber sur le serveur indisponible.
Allez, une autre question : comment fait-on de la répartition de charge passive avec des fréquences arbitraires ? Ben on ne peut pas non plus.
[^] # Re: Ça vient du Web…
Posté par Nico C. . Évalué à 3.
Tu poses des questions de reseau... Les solutions "reseau" pour garantir le fonctionnement d'un site web existent depuis longtemps et sont mises en oeuvre par ceux qui en ont besoin et les moyens.
Ces solutions sont relativement nombreuses et suffisamment variées et/ou complementaires pour repondre a peu pres a n'importe quel besoin et budget (avec plus ou moins d'inconvenients bien sur).
Grosso modo (je vais pas faire un cours de reseau ici), ca va du dns round robin (le plus "basique") a "l'achat" d'un numero d'AS BGP (le plus cher et complexe). Pour ton information, le fameux IPv6 propose aussi des fonctionnalités pour repondre a pas mal de tes questions gratuitement et assez simplement.
Bref, tu fais un mauvais procès aux mauvaises personnes. En tout cas, concernant ton intervention, "on voit que ça vient de gens" qui ne savent pas de quoi ils parlent surtout...
[^] # Re: Ça vient du Web…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
C'est pour la répartition ça, pas la redondance.
À ma connaissance la seule façon d'assurer une redondance complète en effet.
Eh bien tu vois, l'équivalent avec le courrier électronique, qui utilise un protocole moderne qui prévoit nativement des solutions de redondance, contrairement au Web, c'est quelques enregistrements MX. Coût : zéro euros. Coût en temps : dix minutes à tout casser.
[^] # Re: Ça vient du Web…
Posté par Nico C. . Évalué à 0.
Tu as la solution des loadbalancers capable de detecter la "performance" (ou la disponibilité) d'un serveur et agir en consequence (envoyer plus ou moins voire pas du tout de requetes).
Sinon, y'a encore plus simple, tu loues une VM chez un bon hebergeur et roule ma poule. Coté disponilité, c'est le top car tu auras droit a une enorme disponibilité sur le matos, le stockage et le reseau pour un cout tres modique...
Quant a ta comparaison avec les champs MX, c'est tout simplement hors propos.
Parce que si tu crois que la redondance provient des protocoles de messagerie ? Tu te gourres, c'est DNS qui assure cette fonctionnalité avec les champs MX et rien d'autre. Est ce la faute des "gens du web" si DNS fournit une fonctionnalité de débordement pour les serveurs de mail mais pas pour les autres types (A, CNAME, etc) ?
Je repete encore et toujours : tu fais un mauvais procès aux mauvaises personnes et, en plus, tu connais visiblement assez mal le fonctionnement des protocoles de base pour ensuite échafauder des théories foireuses.
De toute facon, y'a pas de magie, SMTP, HTTP, FTP, etc ont tous été faits a peu pres a la meme epoque avec les meme considerations en tete : faut que ca marche, ce soit un protocole "texte" et doit tres simple a implementer. SMTP est pas fondamentalement meilleur que HTTP ou un autre. Il est exactement dans la meme veine que les copains.
Les considerations "actuelles" de securité, redondance, partage de charge et performances ont ete completement "oubliées" a l'epoque. C'est pour ca qu'on a des RFC proposant des especes d'extensions liées a la securité (HTTPS, FTPS, SFTP, SMTPS, etc) plus ou moins bien integrées mais ca reste des ajouts un peu sales.
L'ideal serait de produire de nouveaux protocoles mais ca risque d'etre sacrement long a les mettre en place etant donné l'inertie enorme a ce niveau...
[^] # Re: Ça vient du Web…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Loupé, le protocole SMTP utilise cette fonctionnalité offerte par le DNS.
man SRV, utilisé par Jabber et SIP entre autres. Quand on ne sait pas, on se tait. Errare humanum, sed perseverare diabolicum.
…
[^] # Re: Ça vient du Web…
Posté par Nico C. . Évalué à 4.
Ben ouais, SMTP utilise les champs MX comme HTTP les champs A... il demande a la couche d'en dessous de faire une requete DNS pour trouver l'hote a joindre et il agit en consequence.
La difference tient exclusivement au fait que les champs MX sont plus "puissants" que les champs A.
Bref, tout ca, c'est dans DNS et rien d'autre.
En tout cas, c'est assez dingue ton discours : tu donnes une facon de plus de configurer son DNS d'une maniere assez puissante via les champs SRV mais tu te doutes pas qu'on peut les utiliser aussi pour HTTP et donc obtenir le meme effet avec des serveurs web.
Sauf que, tu vas bien entendu pointer le fait que l'utilisation de SRV pour HTTP n'est pas standardisée (juste un draft incomplet) et qu'il n'est pas implementé dans les navigateurs.
OK mais je repete ce que je dis depuis le debut : en quoi "les gens du web" sont ils en faute dans cette situation ? En quoi est ce de leur competence ? Ils sont aussi dependants du fonctionnement de DNS que tout le monde (les admins de mail servers sont gatés a ce niveau) et ils sont aussi dependant du fonctionnement du reseau en dessous et a ce niveau, tout le monde est logé a la meme enseigne : si t'as des sous, tu fais des trucs geniaux.
Donc au final, j'en reviens toujours et desesperement a la meme chose : tu balances sur "les gens du web" mais leur niveau de competence n'a aucun rapport avec les capacités de redondance ou pas de leur service puisque les outils pour le faire sont soit au niveau reseau, soit au niveau DNS.
Tu fais quoi dans la vie ? t'es admin de serveurs de mail et t'as l'impression de manipuler des technos super top moumoute auquels les "gens du web" n'ont pas accès et dont c'est la faute ?
T'as un discours assez incroyablement incoherent...
[^] # Re: Ça vient du Web…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -2.
Ils ont les enregistrements SRV à leur disposition depuis plus de dix ans. Ils n'ont plus qu'à spécifier comment les utiliser avec HTTP, sachant qu'il n'y a pour cela qu'à suivre leur sémantique qui est déjà précise.
Or, rien ne bouge à ce niveau. Voilà pourquoi je crache sur les gens du Web, en l'occurrence :
En revanche je ne crache pas sur Microsoft parce que de toute façon on ne peut rien attendre d'eux dans un domaine pareil, ils suivront après tous les autres s'ils y sont contraints par la force des choses.
[^] # Re: Ça vient du Web…
Posté par Nico C. . Évalué à 2.
> Ils ont les enregistrements SRV à leur disposition depuis plus de dix ans. Ils n'ont plus qu'à spécifier
> comment les utiliser avec HTTP, sachant qu'il n'y a pour cela qu'à suivre leur sémantique qui est déjà précise.
Le draft existe et il ne manque pas grand chose pour qu'il evolue.
> Or, rien ne bouge à ce niveau. Voilà pourquoi je crache sur les gens du Web, en l'occurrence :
> le W3C en tant qu'organisme de normalisation (fossilisé) ;
Le W3C n'a pas grand chose a voir avec la normalisation de DNS. C'est l'IETF qui s'occupe de ca.
le W3C a deja bien assez a faire avec sa partie. Et vu comme ca remue en ce moment, il est clairement en train de renaitre serieusement.
Faut pas oublier que le W3C n'est que la sommes des "acteurs" qui le composent or pendant la periode IE6, il n'y avait, grosso modo, plus que MS sur le marché et comme il n'avait rien a foutre du web et des normes, forcement le W3C est tombé en stase. Et il a bien fallut qq années pour le reveiller car ca ne se fait pas du jour au lendemain...
> Mozilla en tant qu'éditeur de navigateur (censé améliorer le Web qui aurait bien besoin de rattraper sur
> retard sur, par exemple, le courrier électronique) ;
> Opera en tant qu'éditeur d'un navigateur bien dynamique dans son genre ;
> Google en tant qu'éditeur d'un autre navigateur et que fournisseur de services via le Web (qui a
> habituellement les couilles d'utiliser sa force de frappe pour faire changer les choses, par exemple avec SPDY).
>
Les editeurs de navigateurs sont probablement les plus "coupables" de la bande. Neanmoins, ils sont tres loin de representer la totalité des "gens du web". Quand tu parles des "gens du web", tu parles des dev web, des admins, des hebergeurs, etc. Les editeurs de navigateurs sont importants mais ils restent une minorité.
Faut pas se tromper de cible... mais je crois que je te dis ca depuis le debut.
>En revanche je ne crache pas sur Microsoft parce que de toute façon on ne peut rien attendre d'eux dans un
>domaine pareil, ils suivront après tous les autres s'ils y sont contraints par la force des choses.
On est bien d'accord.
[^] # Re: Ça vient du Web…
Posté par barmic . Évalué à 4.
Comme imbolcus, je ne crois pas que le w3c ai quelque chose à avoir là de dans.
En fait tout les acteurs que tu cite, n'ont qu'un rôle indirect face à ce problème, c'est à l'IETF ou plus généralement à l'Internet Society d'éditer des RFC. D'ailleurs en allant voir leur site, je vois qu'il y a un travail fait autour de httpbis qui serait une nouvelle version de http. Tu peut voir l'état d'avancement ici par exemple :
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/
Il semble qu'intervenir dans leur groupe de travail est quelque chose de facile et ne demande rien d'autre que de s'y inscrire (en fait même pas on peut envoyer un mail directement).
Tu connais nettement mieux que moi DNS et les champs SRV, peut être que tu pourrais envoyer un mail voir comment ils réagissent ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ça vient du Web…
Posté par geb . Évalué à 3.
SIGBLAH.
Comme dit plus haut, c'est plutôt du ressort de l'IETF d'ailleurs, il y a eu plusieurs tentatives de standardisation au sein des workgroups DNS .. sans succès. Preuve que c'est sans doute plus un problème de réseau que de "gens du web". Preuve également que cela n'est pas si simple que tu le penses (exemples: CNAME, wildcard , DNS64..).
Et si tu vois ça d'un angle réseau, tu remarqueras qu'il y a déjà de nombreuses solutions possibles, en particulier en jouant sur les DNS (roundrobin, geodns, TTL nul ..) mais aussi au niveau d'http lui même.
Bien évidemment, si tu as une solution magique, plus intelligente que toutes celles déjà proposées tu ne dois pas être sans savoir que l'IETF est ouverte à tous (et son fonctionnement est documenté dans des RFCs)... Par contre, à mon avis, le latin et traiter les gens d'idiots et d'incompétents, il vaut mieux oublier.
[^] # Re: Ça vient du Web…
Posté par Antoine . Évalué à 6.
M'enfin, j'éviterais d'utiliser SIP comme exemple d'un protocole bien fichu. Dans le genre usine à gaz inimplémentable proprement, ils ont fait fort.
[^] # Re: Ça vient du Web…
Posté par barmic . Évalué à 3.
Sans rire ? C'est ceux qui font du web qui tente de résoudre un problème d'authentification web ? Les salauds !
Il est pourtant assez pertinent d'utiliser du web pour faire de l'authentification web.
Le reproche que tu fais, c'est un reproche fais au web d'une manière général. Je vois pas en quoi c'est un problème pour l'authentification et pas pour les sites web eux même. De plus de ce que j'ai cru comprendre d'OpenID, le problème était le même.
Comment imagine-tu une bonne solution ? Utilisation de SMTP (tout serveur web doit être couplé à un serveur SMTP et on se farde une réticence beaucoup plus forte de la part des « gens du web » et on empêche les « gens du web » qui n'ont pas un accès complet à leur serveur de l'utiliser).
C'est une vraie question, je comprends le problème que tu soulève, mais pour moi, il devrait se résoudre pour HTTP/HTTPS d'une manière plus générale (dans une RFC) parce qu'il n'y a pas de raison que le web n'en profite pas (et je ne sais pas comment se débrouillent google/amazone par exemple, mais je suis sûr qu'ils apprécierais de payer moins pour avoir le même niveau de disponibilité).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ça vient du Web…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Je pense simplement que, si Mozilla veut améliorer le Web, il ne serait que temps de s'attaquer enfin aux problèmes de redondance et de répartition de charge, qui ont été réglés depuis des décennies pour les courrier électronique par exemple.
[^] # Re: Ça vient du Web…
Posté par DLFP est mort . Évalué à 5.
Malheureusement le développeur Web ne connaît pas grand-chose en dehors du Web et veut absolument tout réinventer (en général, mal).
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Ça vient du Web…
Posté par barmic . Évalué à -2.
Qu'est ce qu'ils sont nuls c'est « gens du web » …
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ça vient du Web…
Posté par Antoine . Évalué à 2.
Il faut en tout cas leur reconnaître un certain courage, à tout vouloir réimplémenter un peu n'importe comment. Et si dans les gens du Web on inclut avant tout le W3C, je dirais que oui ils sont franchement nuls.
[^] # Re: Ça vient du Web…
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 2.
Si tu inclus les bras cassés de WHATWG et de HTML5 en plus, c'est pire !
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
# serrure, dormant et ouvrant
Posté par bubar🦥 (Mastodon) . Évalué à 6.
//dredi
Bon, Mozilla va avoir la serrure. Maintenant il va leur manquer la porte qui va autour. (Mozilla va t elle se lancer dans le "réseau social" ?)
à propos de porte ...
[^] # Re: serrure, dormant et ouvrant
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Du calme, c'est prématuré : BrowserId et VerifiedMail ne sont absolument pas prêts, ni en terme de code ni en terme de documentation et de spécification. C'est juste un projet…
[^] # Re: serrure, dormant et ouvrant
Posté par CrEv (site web personnel) . Évalué à 8.
?
En même temps ils annoncent vouloir sortir un OS alors bon...
# Rappel
Posté par ploum (site web personnel, Mastodon) . Évalué à 10.
Pour que la discussion ne soit pas redondante, voici ce qui a déjà été dit:
http://www.clochix.net/post/2011/07/04/G%C3%A9rez-votre-identit%C3%A9-num%C3%A9rique-avec-MozillaID
https://linuxfr.org/users/ploum/journaux/identit%C3%A9-num%C3%A9rique-mozilla-sy-met
Mes livres CC By-SA : https://ploum.net/livres.html
# Doublon
Posté par Jean B . Évalué à 10.
On a aussi entendu parlé du journal de ploum sur exactement le même sujet
# Ceux qui ont oublié l'histoire, sont condamnés à la revivre.
Posté par phxonx . Évalué à 3.
C'est assez amusant ces "problèmes" OpenID et consors, ca me rapelle furieusement un truc...
Ah oui
http://web.mit.edu/kerberos/dialogue.html
En anglais malheureusement (de toute façon aujourd'hui c'est le jour ou je me fais moinser pour cause de 1997)
[^] # Re: Ceux qui ont oublié l'histoire, sont condamnés à la revivre.
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Oui, mais non. Kerberos c'est tout simplement une usine à gaz incompréhensible, entre le serveur d'identification, le serveur de tickets, le serveur de clefs de tickets ou je ne sais quoi.
[^] # Re: Ceux qui ont oublié l'histoire, sont condamnés à la revivre.
Posté par Martin Peres (site web personnel) . Évalué à 3.
Tu n'exagères pas un petit peu? C'est pas incompréhensible, c'est juste pas adapté à tous les cas d'utilisations (besoin d'un temps partagé) ;) Et puis, si même microsoft l'a mis en place (dans Active Directory), c'est que ça doit pas être si dur que ça de le faire comprendre aux admins (bonne journée à eux).
Perso, je vois pas comment quelqu'un pourrait garantir autant de propriétés de sécurité avec un protocole plus simple. C'est élégant d'un point de vue sécu, beaucoup moins d'un point de vue conso énergétique et latence d'accès aux services.
# OpenID ou OAuth ?
Posté par CrEv (site web personnel) . Évalué à 1.
Certains ?
Google entre autre utilise surtout OAuth
(http://googlecode.blogspot.com/2011/03/making-auth-easier-oauth-20-for-google.html par exemple)
[^] # Re: OpenID ou OAuth ?
Posté par Jean B . Évalué à 2.
Ouais… C'est disponible depuis Mars 2011 et d'après leur doc c'est encore expérimental, tandis qu'ils proposent OpenID depuis pas mal d'années (au moins 4 ou 5).
Le surtout est donc peut être un poil exagéré.
[^] # Re: OpenID ou OAuth ?
Posté par CrEv (site web personnel) . Évalué à 2.
C'est bien aussi pour ça que, malgré le lien, je parle de OAuth et non OAuth2
http://code.google.com/intl/fr-FR/apis/accounts/docs/OAuth.html est là depuis 2008 et n'est pas expérimental.
C'est surtout que j'ai l'impression, depuis un moment, que tout le monde crache sur OpenID au profit de OAuth, y compris Google, twitter, facebook, etc.
http://developers.facebook.com/docs/authentication/
https://dev.twitter.com/docs/auth
Donc voilà, comparer à OpenID c'est cool, mais j'ai surtout l'impression que OpenID n'a surtout juste pas réussi, donc le comparer est biaisé. Il serait intéressant de le comparer à OAuth, mais j'ai l'impression que c'est pas tout à fait le même objectif (peut-être que je me trompe).
[^] # Re: OpenID ou OAuth ?
Posté par Jean B . Évalué à 5.
Le gros problème d'OAuth c'est que à la base ce n'est pas prévu pour faire de l'authentification, juste pour autoriser une application à accéder à une partie d'une API.
De là on s'est mis à authentifier les utilisateurs via OAuth en récupérant via cette autorisation un identifiant unique sur Facebook/Twitter. Alors certes ça marchotte, cependant tu doit te taper un connecteur spécifique par service ainsi qu'un couple de clé. Alors qu'avec OpenID tu l'implémente une fois et tous les provider OpenID sont acceptés.
C'est ce que j'expliquait dans un de mes vieux commentaires
[^] # Re: OpenID ou OAuth ?
Posté par Jean B . Évalué à 2.
J'oubliait, c'est d'ailleurs pour ça que Google proposait d'utiliser les OpenID + OAuth1: http://code.google.com/intl/fr-FR/apis/accounts/docs/OpenID.html#oauth
[^] # Re: OpenID ou OAuth ?
Posté par DLFP est mort . Évalué à 2.
D'ailleurs, un article sur le sujet : http://softwareas.com/oauth-openid-youre-barking-up-the-wrong-tree-if-you-think-theyre-the-same-thing
DLFP >> PCInpact > Numerama >> LinuxFr.org
# mouif
Posté par Gniarf . Évalué à 10.
(je constate toujours le joyeux mélange habituel identification/authentification alors qu'on parle au départ d'éviter à l'utilisateur de retenir 25 mots de passe différents ou d'utiliser le même partout)
j'ai la ferme intention de continuer à utiliser pratiquement une adresse email par site utilisé (que ça soit un identifiant ou un moyen de me contacter) parce que je tiens à pouvoir fermer le tuyau dès que l'adresse en question se promènera sur Internet (site piraté, site marchand beaucoup trop affectueux, spam...). un identifiant ne permettant PAS de me contacter aussi directement, je veux bien tenter.
alors déjà si le navigateur ne gère pas ça de façon décente dans son interface utilisateur, c'est poubelle direct. ah, des fois, j'aurai plusieurs comptes sur un même site.
et si l'auto-hébergement devient très mal vu (l'utilisateur est le propre certificateur de ses adresses, et les sites autres qu'amateurs réclameraient une adresse d'un bébergeur qui fait sérieux, soit au final se retrouver avec 2-3 emails-identifiants en tout) ça va m'être un peu inutile aussi.
demander à ce que j'utilise une adresse email publique et universelle (et accessoirement censée m'identifier) est à peine moins ridicule que me faire utiliser un mot de passe universel qui sera transmis à tous les sites que j'utilise. oui, mais non.
# OpenID
Posté par Antoine . Évalué à 4.
De mon point de vue deux problèmes :
Du coup, j'ai abandonné OpenID.
[^] # Re: OpenID
Posté par Grunt . Évalué à 4.
SimpleID fonctionne pas trop mal.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: OpenID
Posté par Antoine . Évalué à 2.
Merci, j'irai jeter un oeil.
[^] # Re: OpenID
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 2.
Et comme implémentation client PHP5, lightopenid.
(Sinon SimpleID c'est bien oui.)
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: OpenID
Posté par Antoine . Évalué à 3.
Bon, j'ai installé et configuré SimpleID (c'est un peu moins facile que je ne l'espérais), mais mon OpenID merde avec un tiers des sites que j'ai essayés... Déjà un certain nombre d'entre eux refusent l'URL en HTTPS !
[^] # Re: OpenID
Posté par Grunt . Évalué à 2.
Mh, tu cherchais un service OpenID qui fonctionne, pas un service OpenID qui contourne les bugs de certains sites :]
Tu n'as pas essayé en rendant ton URL OpenID disponible via HTTP?
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: OpenID
Posté par Antoine . Évalué à 2.
Certes, SimpleID n'est probablement pas à blâmer, mais ça veut dire qu'OpenID en tant que standard a encore du chemin à faire.
Si le service OpenID lui-même tourne sur une URL HTTPS, je ne suis pas sûr que ça fasse une différence, si ?
[^] # Re: OpenID
Posté par Larry Cow . Évalué à 2.
Si le service OpenID lui-même tourne sur une URL HTTPS, je ne suis pas sûr que ça fasse une différence, si ?
Pas certain de comprendre. Le consommateur d'OpenID a besoin de contacter l'URL que tu lui passe, celle-ci pouvant être en HTTP ou en HTTPS, au choix.
Là-dessus, deux comportements peuvent répondre à une URL en HTTPS : soit le consommateur reconnaît le certificat du fournisseur d'identité, soit pas. Dans ce second cas, effectivement, ça pose souci (notamment pour tous les autosignés et CA privées/peu répandues). Ne serait-ce pas ça qui te pose problème?
Et autant je suis quasiment certain que l'on peut désactiver la vérification de certificats dans n'importe quel outil consommateur d'OpenID, autant je me doute bien qu'un nombre non-négligeable de déploiements exigent un certificat valide.
Ce pourquoi j'aurais tendance à répondre : pas de HTTPS pour les identifiants OpenID, c'est plus simple pour tout le monde (en plus, ça permet de les taper sans URL-scheme, ça va plus vite). En revanche, évidemment, du SSL pour sécuriser la page d'authentification (vers laquelle on ne manquera pas d'être redirigé) semble inévitable.
[^] # Re: OpenID
Posté par Antoine . Évalué à 2.
Non, je me suis fait chier à prendre un certificat chez StartSSL précisément pour l'éviter :-)
Ceci dit HTTPS ne semble pas être le seul problème ; parmi les sites qui refusent mon adresse OpenID, j'en vois qui tapent bien sur le serveur (des requêtes apparaissent dans les logs), mais qui ne vont pas plus loin et refusent l'authentification.
[^] # Re: OpenID
Posté par Larry Cow . Évalué à 2.
Non, je me suis fait chier à prendre un certificat chez StartSSL précisément pour l'éviter :-)
Tu es certain que ton consommateur d'OpenID reconnaît correctement StartSSL? :p
Ceci dit HTTPS ne semble pas être le seul problème ; parmi les sites qui refusent mon adresse OpenID, j'en vois qui tapent bien sur le serveur (des requêtes apparaissent dans les logs), mais qui ne vont pas plus loin et refusent l'authentification.
C'est probablement un peu tard, mais "on" (c'est à dire les gens qui se sont un peu investis dans OpenID) aurait du essayer de mettre en place une matrice de compatibilité entre solutions et/ou services.
[^] # Re: OpenID
Posté par Antoine . Évalué à 2.
Si Firefox et curl le reconnaissent, ça devrait aller, non ?
Hé, je ne suis pas un expert, mais à ce que j'en ai vu, beaucoup de gens (qui implémentent des producteurs ou consommateurs d'identités OpenID) se sont plaints de l'absence de suite de tests officielle.
[^] # Re: OpenID
Posté par Larry Cow . Évalué à 2.
Si Firefox et curl le reconnaissent, ça devrait aller, non ?
TON Firefox et TON curl. Par contre, le mec qui a déployé (voire codé) ton consommateur OpenID, il a pu utiliser tout et n'importe quoi, n'importe comment. Donc aucune garantie de ce côté-là.
Le premier truc à vérifier serait donc d'essayer avec un OpenID non-SSL.
l'absence de suite de tests officielle.
Oui et non (je ne suis pas un expert non plus). Il y avait les exemples de JanRain (openidenabled.com) qui remplissaient plus ou moins cet office. Sauf qu'effectivement, ils ont fini par se désintéresser de l'affaire. Mais ça, on ne pouvait pas le savoir à l'époque.
[^] # Re: OpenID
Posté par Grunt . Évalué à 2.
En fait, pour m'être fait jeter par blogspot même avec une URL sans HTTP, je me demande si certaines mises en place de OpenID ne se limitent pas à une liste restreinte de fournisseurs d'auth.
Ce qui, pour le coup, enlève tout intérêt à OpenID.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: OpenID
Posté par Larry Cow . Évalué à 2.
Certaines, oui, clairement. Le truc, c'est qu'on n'aurait pas dû les autoriser à utiliser la symbologie OpenID dans ce cas. Mais encore une fois, on n'a normalisé que la technique (et encore...), pas les usages.
Dans le même genre, beaucoup de gens (dont moi) ont commencé en utilisant l'URL fournie par l'utilisateur comme un identifiant. Jusqu'à ce que Google débarque avec son URL unique pour tous les utilisateurs. Et là, kaboom. Et pourtant ça collait à la norme.
# KISS
Posté par devnewton 🍺 (site web personnel) . Évalué à -1.
Au lieu d'inventer un système complexe qui demande de modifier tous les sites de la terre, Mozilla devrait plutôt permettre de synchroniser de façon sécurisée le gestionnaire de mot de passe entre plusieurs PC.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: KISS
Posté par barmic . Évalué à 6.
Tu parle de Firefox Sync ?
C'est génial quand tu es dans un cybercaffé.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: KISS
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Si tu es dans un cybercafé, tu es en milieu hostile, donc tu n'utilises pas tes mots de passe...
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: KISS
Posté par barmic . Évalué à 3.
Quand tu n'a pas internet à la maison, tu n'utilise pas l'Internet.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: KISS
Posté par barmic . Évalué à 2.
Mais j'aurais aussi bien pu parler de quand tu es chez un(e) ami(e) ou de la famille.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: KISS
Posté par Paul . Évalué à 0.
Comme tout le monde, tu synchronise Firefox avec ton smartphone.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.