Repository with sources and generator of https://larlet.fr/david/ https://larlet.fr/david/
Вы не можете выбрать более 25 тем Темы должны начинаться с буквы или цифры, могут содержать дефисы(-) и должны содержать не более 35 символов.

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141
  1. <div class="comment" typeof="schema:UserComments">
  2. <p class="comment-meta">
  3. <span class="comment-author" property="schema:creator">NiKo</span> le <span class="comment-date" property="schema:commentTime">26/01/2009</span> :
  4. </p>
  5. <div class="comment-content" property="schema:commentText">
  6. <p>Tu devrais nous écrire tout ça... en anglais.</p>
  7. <p>Parce que c&#39;est juste essentiel ce que tu dis là.</p>
  8. </div>
  9. </div>
  10. <div class="comment" typeof="schema:UserComments">
  11. <p class="comment-meta">
  12. <span class="comment-author" property="schema:creator">karl Dubost</span> le <span class="comment-date" property="schema:commentTime">26/01/2009</span> :
  13. </p>
  14. <div class="comment-content" property="schema:commentText">
  15. <p>Je vais le traduire aujourd&#39;hui sauf si David me dit qu&#39;il l&#39;a déjà fait.</p>
  16. </div>
  17. </div>
  18. <div class="comment" typeof="schema:UserComments">
  19. <p class="comment-meta">
  20. <span class="comment-author" property="schema:creator">Damien B</span> le <span class="comment-date" property="schema:commentTime">26/01/2009</span> :
  21. </p>
  22. <div class="comment-content" property="schema:commentText">
  23. <p>&quot;Il n&#39;y a aucune notion de certification m&#39;assurant que cette adresse correspond à une personne donnée [...] cette problématique n&#39;est pas résolue par OpenID (du moins pour l&#39;instant).&quot;</p>
  24. <p>Pour y arriver, il faudrait une vérification d&#39;identité ET faire confiance au fournisseur OpenID dans cette vérification d&#39;identité. Pour en arriver là, le plus simple est de jeter OpenID à la poubelle et faire une bonne vieille authentification par certificat :D</p>
  25. <p>&quot;OAuth permet uniquement de gérer plus finement les accès à ses données sur un service.&quot;</p>
  26. <p>Wo l&#39;aut&#39;, il essaie de nous faire croire que la gestion des autorisations est normalisée dans OAuth :-)</p>
  27. </div>
  28. </div>
  29. <div class="comment" typeof="schema:UserComments">
  30. <p class="comment-meta">
  31. <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">26/01/2009</span> :
  32. </p>
  33. <div class="comment-content" property="schema:commentText">
  34. <p>@NiKo : mon niveau d&#39;anglais m&#39;interdit toute forme de publication sérieuse dans cette langue malheureusement... (et puis le but de ce blog c&#39;était aussi de pouvoir communiquer en français sur ce genre de problématiques).</p>
  35. <p>@Karl Dubost : je ne l&#39;ai pas traduit, par contre c&#39;est vrai qu&#39;il y a quelques inexactitudes concernant la sécurité et OAuth, comme nous en discutons sur <a href="http://lists.w3.org/Archives/Public/public-social-web-talk/">http://lists.w3.org/Archives/Public/public-social-web-talk/</a> (mais tu dois être au courant ;-)).<br />Ma conclusion c&#39;est qu&#39;il y a en effet un gain au niveau sécurité en théorie mais dans les faits ce n&#39;est malheureusement pas le cas (en tout cas pour l&#39;instant).</p>
  36. <p>@Damien B : ah, tes commentaires me manquaient !</p>
  37. <p>&gt; il faudrait une vérification d&#39;identité ET faire confiance au fournisseur OpenID dans cette vérification d&#39;identité</p>
  38. <p>Tout à fait, après peut-on faire confiance à des fournisseurs comme l&#39;état ou les communes par exemple ? (ça va dépendre des pays, etc bien sûr)</p>
  39. <p>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&#39;arriver à percer, je ne pense pas et c&#39;est un peu la même chose là... enfin ça dépend de l&#39;évolution des navigateurs en parallèle aussi.</p>
  40. <p>&gt; il essaie de nous faire croire que la gestion des autorisations est normalisée dans OAuth</p>
  41. <p>En effet, ça dépend de l&#39;implémentation que l&#39;on en fait, d&#39;où le nombre d&#39;extensions qui fleurissent pour spécifier quelles ressources sont concernées, etc. Note que c&#39;est un peu mieux précisé dans la spec IETF:<br /><a href="http://oauth.googlecode.com/svn/spec/core/IETF/drafts/1/draft-hammer-oauth-00.txt">http://oauth.googlecode.com/svn/spec/core/IETF/drafts/1/draft-hammer-oauth-00.txt</a></p>
  42. <p>o The Service Provider presents to the User information about the<br /> Consumer requesting access (as registered by the Consumer<br /> Developer). The information includes the duration of the access<br /> and the Protected Resources provided. The information MAY include<br /> other details specific to the Service Provider.</p>
  43. <p>Mais ça reste bien flou :-)</p>
  44. </div>
  45. </div>
  46. <div class="comment" typeof="schema:UserComments">
  47. <p class="comment-meta">
  48. <span class="comment-author" property="schema:creator">Neovov</span> le <span class="comment-date" property="schema:commentTime">26/01/2009</span> :
  49. </p>
  50. <div class="comment-content" property="schema:commentText">
  51. <p>Merci beaucoup David, je vais mettre à jour mon dossier sur l&#39;identité numérique ;-) .</p>
  52. <p>Par contre, je vois mal l&#39;é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&#39;on est la personne qu&#39;on prétend être (ils ont des coordonnées bancaires et postales quand même). Mais ça pose d&#39;autres problématiques…</p>
  53. <p>Par contre pour OAuth, en quoi ce n&#39;est pas si sécurisé que ça ? Parce que les consumers ne précisent pas les données qu&#39;ils vont utiliser ?</p>
  54. </div>
  55. </div>
  56. <div class="comment" typeof="schema:UserComments">
  57. <p class="comment-meta">
  58. <span class="comment-author" property="schema:creator">karl Dubost</span> le <span class="comment-date" property="schema:commentTime">26/01/2009</span> :
  59. </p>
  60. <div class="comment-content" property="schema:commentText">
  61. <p>Et voila, tu peux en faire ce que tu veux :)<br /><a href="http://www.la-grange.net/2009/01/26/openid-oauth">http://www.la-grange.net/2009/01/26/openid-oauth</a></p>
  62. </div>
  63. </div>
  64. <div class="comment" typeof="schema:UserComments">
  65. <p class="comment-meta">
  66. <span class="comment-author" property="schema:creator">Damien B</span> le <span class="comment-date" property="schema:commentTime">27/01/2009</span> :
  67. </p>
  68. <div class="comment-content" property="schema:commentText">
  69. <p>@David<br />&quot;Est-ce que les clés PGP ont une chance d&#39;arriver à percer&quot;</p>
  70. <p>Non, c&#39;est du décentralisé :)</p>
  71. <p>&quot;Note que c&#39;est un peu mieux précisé dans la spec IETF&quot;</p>
  72. <p>&quot;draft-00.txt&quot;, ah ouais, ça fouette :) &quot;The information MAY include other details &quot; : oh, c&#39;est précis comme une spécification de µFormat.</p>
  73. </div>
  74. </div>
  75. <div class="comment" typeof="schema:UserComments">
  76. <p class="comment-meta">
  77. <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">27/01/2009</span> :
  78. </p>
  79. <div class="comment-content" property="schema:commentText">
  80. <p>@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&#39;autres problèmes et je ne vois pas pourquoi l&#39;é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&#39;inertie c&#39;est pas près d&#39;arriver...).</p>
  81. <p>&gt; Par contre pour OAuth, en quoi ce n&#39;est pas si sécurisé que ça ? Parce que les consumers ne précisent pas les données qu&#39;ils vont utiliser ?</p>
  82. <p>Comme le soulignait Damien, la spec est très imprécise à ce niveau, le service provider peut faire ce qu&#39;il veut : d&#39;un gros bouton qui signifie &quot;Donner toutes mes données en lecture/écriture à untel&quot; à une gestion beaucoup plus fine par ressource. Bon en 1.0, tu n&#39;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...</p>
  83. <p>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&#39;ils savent détecter un hameçonnage (phishing), alors OAuth est vraiment mieux. Sinon ça laisse toujours ta porte grande ouverte (comme l&#39;était la demande de login/pass) mais tes fenêtre sont mieux renforcées (youpi).</p>
  84. <p>@karl Dubost : merci ! Bon je sais pas quoi en faire du coup :p<br />Soit je la met à la suite du billet actuel, soit je fais un lien vers la-grange, ce que j&#39;ai commencé à faire, mais il va falloir nettoyer un poil plus le html (au moins le title et les liens).</p>
  85. <p>@Damien B : En même temps il faut reconnaître que c&#39;est pas évident à spécifier non plus si tu veux rester assez générique.&lt;/avocatdudiable&gt;</p>
  86. </div>
  87. </div>
  88. <div class="comment" typeof="schema:UserComments">
  89. <p class="comment-meta">
  90. <span class="comment-author" property="schema:creator">Clément</span> le <span class="comment-date" property="schema:commentTime">05/02/2009</span> :
  91. </p>
  92. <div class="comment-content" property="schema:commentText">
  93. <p>De mon point de vue l&#39;avantage qu&#39;apporte la &quot;méthode&quot; d&#39;authentification Oauth en terme de sécurité est qu&#39;elle certifie à l&#39;utilisateur que ses identifiants permettant de se connecter au service auquel il souhaite accéder ne pourront pas être interceptés par l&#39;application tierce à partir de laquelle il agit.</p>
  94. </div>
  95. </div>
  96. <div class="comment" typeof="schema:UserComments">
  97. <p class="comment-meta">
  98. <span class="comment-author" property="schema:creator">akaj</span> le <span class="comment-date" property="schema:commentTime">09/03/2009</span> :
  99. </p>
  100. <div class="comment-content" property="schema:commentText">
  101. <p>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&#39;état... J&#39;ai l&#39;impression que cela va donner lieu à divers vagues problèmes sur la vie privée mais bon.</p>
  102. <p>merci encore pour tous ces postes qui me rassure.</p>
  103. </div>
  104. </div>
  105. <div class="comment" typeof="schema:UserComments">
  106. <p class="comment-meta">
  107. <span class="comment-author" property="schema:creator">Boboss</span> le <span class="comment-date" property="schema:commentTime">11/01/2012</span> :
  108. </p>
  109. <div class="comment-content" property="schema:commentText">
  110. <p>Twitter utilise exclusivement OAuth pour ses API depuis le 31 août 2010.</p>
  111. <p><a href="https://dev.twitter.com/docs/auth">https://dev.twitter.com/docs/auth</a></p>
  112. <p>=)</p>
  113. </div>
  114. </div>