davidbgk
/
larlet-fr-david


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248
							<!doctype html>
<html lang=fr>
<head>
  <!-- Always define the charset before the title -->
  <meta charset=utf-8>
  <title>Mieux communiquer sur OpenID et OAuth — Biologeek — David Larlet</title>
  <!-- Define a viewport to mobile devices to use - telling the browser to assume that the page is as wide as the device (width=device-width) and setting the initial page zoom level to be 1 (initial-scale=1.0) -->
  <meta name="viewport" content="width=device-width, initial-scale=1"/>
  <!-- Fake favicon, to avoid extra request to the server -->
  <link rel="icon" href="data:;base64,iVBORw0KGgo=">
  <link type="application/atom+xml" rel="alternate" title="Feed" href="/david/log/" />
  <link rel="manifest" href="/manifest.json">
  
  <link rel="stylesheet" href="/static/david/css/larlet-david-_J6Rv.css" data-instant-track />
  
  <noscript>
    <style type="text/css">
      /* Otherwise fonts are loaded by JS for faster initial rendering. See scripts at the bottom. */
      body {
        font-family: 'EquityTextB', serif;
      }
      h1, h2, h3, h4, h5, h6, time, nav a, nav a:link, nav a:visited {
        font-family: 'EquityCapsB', sans-serif;
        font-variant: normal;
      }
    </style>
  </noscript>
  
  <!-- Canonical URL for SEO purposes -->
  <link rel="canonical" href="https://larlet.fr/david/biologeek/archives/20090125-mieux-communiquer-sur-openid-et-oauth">

</head>
<body>
  <div>
    
    <header>
      <nav>
        <p>
          <small>
            Je suis <a href="/david/" title="Profil public">David Larlet</a>, <a href="/david/pro/" title="Activité professionnelle">artisan</a> du web qui vous <a href="/david/pro/accompagnement/" title="Activité d’accompagnement">accompagne</a><span class="more-infos"> dans l’acquisition de savoirs pour concevoir des <a href="/david/pro/produits-essentiels/" title="Qu’est-ce qu’un produit essentiel ?">produits essentiels</a></span>. <span class="more-more-infos">Discutons ensemble d’une <a href="/david/pro/devis/" title="En savoir plus">non-demande de devis</a>.</span> Je partage ici mes <a href="/david/blog/" title="Expériences bienveillantes">réflexions</a> et <a href="/david/correspondances/2017/" title="Lettres hebdomadaires">correspondances</a>.
          </small>
        </p>
      </nav>
    </header>
    
    
  <section>
    <h1 property="schema:name">Mieux communiquer sur OpenID et OAuth</h1>
    <article typeof="schema:BlogPosting">
      <div property="schema:articleBody">
        <img src="/static/david/biologeek/images/logos/twitter.png" alt="vignette" style="float:left; margin: 0.5em 1em;" property="schema:thumbnailUrl" />
        <p>J'étais déjà passablement irrité par <a href="http://intertwingly.net/blog/2009/01/16/WHATWG-FAQ?#c1232798089">un commentaire de Sam Ruby</a>, mais lorsque je lis <a href="http://www.readwriteweb.com/archives/why_twitters_new_oauth_matters.php">de telles énormités</a> je me sens obligé de réagir. Je ne vais pas énumérer point par point les incohérences déjà décrites par <a href="http://stut.net/">Stuart Dallas</a> dans les commentaires mais plutôt essayer d'expliquer le plus simplement possible de quoi on parle.</p>
<p><strong>[edit]</strong> : English readers, take a look at <a href="http://www.la-grange.net/2009/01/26/openid-oauth">this excellent translation from Karl Dubost</a>.</p>
<h2>OpenID</h2>
<p>Prenons le cas concret d'un blog. Lorsque vous utilisez <strong>OpenID, vous prouvez uniquement que la personne qui a laissé un commentaire avec une adresse donnée sera toujours la même</strong>. 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).</p>
<h2>OAuth</h2>
<p><strong>OAuth permet uniquement de gérer plus finement les accès à ses données sur un service</strong>. Ç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.</p>
<p>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).</p>
<p><strong>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.</strong></p>
<h3>Aller plus loin</h3>
<ul>
<li><a href="http://factoryjoe.com/blog/2009/01/02/twitter-and-the-password-anti-pattern/">Twitter and the Password Anti-Pattern</a></li>
<li><a href="http://blog.joncrosby.me/post/68470033/oauth-phishing-and-twitter">OAuth, Phishing, and Twitter</a></li>
<li><a href="http://stut.net/blog/2009/01/24/oauth-and-twitter-realistic-expectations/">OAuth and Twitter: Realistic expectations</a> (découvert après la rédaction de ce billet en voulant faire un lien dans l'intro, dommage ça m'aurait épargné de la salive numérique ;-))</li>
</ul>
      </div>
    </article>
    <footer>
      <h6 property="schema:datePublished">— 25/01/2009</h6>
    </footer>
  </section>
  <section>
    <div>
      <h3>Articles peut-être en rapport</h3>
      <ul>
        <li><a href="/david/biologeek/archives/20090221-son-propre-tinyurl-en-python-et-html5-avec-webpy/" title="Accès à Son propre TinyURL en Python et HTML5 avec webpy">Son propre TinyURL en Python et HTML5 avec webpy</a></li>
        <li><a href="/david/biologeek/archives/20081117-le-web-semantique-ou-limportance-des-donnees-liees/" title="Accès à ★ Le Web Sémantique ou l&#39;importance des données liées">★ Le Web Sémantique ou l&#39;importance des données liées</a></li>
        <li><a href="/david/biologeek/archives/20080716-differences-entre-identification-autorisation-et-authentification/" title="Accès à Différences entre identification, autorisation et authentification">Différences entre identification, autorisation et authentification</a></li>
      </ul>
    </div>
  </section>
  <section>
    <div id="comments">
      <h3>Commentaires</h3>
      
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">NiKo</span> le <span class="comment-date" property="schema:commentTime">26/01/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Tu devrais nous écrire tout ça... en anglais.</p>

<p>Parce que c&#39;est juste essentiel ce que tu dis là.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">karl Dubost</span> le <span class="comment-date" property="schema:commentTime">26/01/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Je vais le traduire aujourd&#39;hui sauf si David me dit qu&#39;il l&#39;a déjà fait.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Damien B</span> le <span class="comment-date" property="schema:commentTime">26/01/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <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>

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

<p>&quot;OAuth permet uniquement de gérer plus finement les accès à ses données sur un service.&quot;</p>

<p>Wo l&#39;aut&#39;, il essaie de nous faire croire que la gestion des autorisations est normalisée dans OAuth :-)</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">26/01/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <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>

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

<p>@Damien B : ah, tes commentaires me manquaient !</p>

<p>&gt; il faudrait une vérification d&#39;identité ET faire confiance au fournisseur OpenID dans cette vérification d&#39;identité</p>

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

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

<p>&gt; il essaie de nous faire croire que la gestion des autorisations est normalisée dans OAuth</p>

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

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

<p>Mais ça reste bien flou :-)</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Neovov</span> le <span class="comment-date" property="schema:commentTime">26/01/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Merci beaucoup David, je vais mettre à jour mon dossier sur l&#39;identité numérique ;-) .</p>

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

<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>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">karl Dubost</span> le <span class="comment-date" property="schema:commentTime">26/01/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <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>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Damien B</span> le <span class="comment-date" property="schema:commentTime">27/01/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@David<br />&quot;Est-ce que les clés PGP ont une chance d&#39;arriver à percer&quot;</p>

<p>Non, c&#39;est du décentralisé :)</p>

<p>&quot;Note que c&#39;est un peu mieux précisé dans la spec IETF&quot;</p>

<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>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">27/01/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <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>

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

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

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

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

<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>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Clément</span> le <span class="comment-date" property="schema:commentTime">05/02/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <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>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">akaj</span> le <span class="comment-date" property="schema:commentTime">09/03/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <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>

<p>merci encore pour tous ces postes qui me rassure.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Boboss</span> le <span class="comment-date" property="schema:commentTime">11/01/2012</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Twitter utilise exclusivement OAuth pour ses API depuis le 31 août 2010.</p>

<p><a href="https://dev.twitter.com/docs/auth">https://dev.twitter.com/docs/auth</a></p>

<p>=)</p>
    </div>
</div>

    </div>
  </section>

    
    <footer>
      <nav>
        <p>
          <small>
            Je réponds quasiment toujours aux <a href="m&#x61;ilto:d&#x61;vid%40l&#x61;rlet&#46;fr" title="Envoyer un email">emails</a> (<a href="/david/signature/" title="Ma signature actuelle avec possibilité de chiffrement">signés</a>) et vous pouvez me rencontrer à Montréal. <span class="more-infos">N’hésitez pas à <a href="/david/log/" title="Être tenu informé des mises à jour">vous abonner</a> pour être tenu informé des publications récentes.</span>
          </small>
        </p>
      </nav>
    </footer>
    
  </div>
  
  <script src="/static/david/js/larlet-david-3ee43f.js" data-no-instant></script>
  
  <script data-no-instant>InstantClick.init()</script>
  
</body>
</html>