davidbgk
/
larlet-fr-david


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355
							<!doctype html>
<html lang=fr>
<head>
  <!-- Always define the charset before the title -->
  <meta charset=utf-8>
  <title>Différences entre identification, autorisation et authentification — 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/20080716-differences-entre-identification-autorisation-et-authentification">

</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">Différences entre identification, autorisation et authentification</h1>
    <article typeof="schema:BlogPosting">
      <div property="schema:articleBody">
        <img src="/static/david/biologeek/images/logos/id_authz_authn.png" alt="vignette" style="float:left; margin: 0.5em 1em;" property="schema:thumbnailUrl" />
        <p>J'étais en train de lire <a href="http://www.fredcavazza.net/2008/07/16/vers-de-la-micro-authentification-avec-microid/">le billet de Fred Cavazza sur MicroID</a> et plus particulièrement les commentaires mais ça part un peu dans tous les sens, principalement pour un problème de vocabulaire. Je vais essayer de débroussailler un peu car la confusion est très souvent faite (notamment car auth peut signifier authorization et authentication en anglais d'où la nécessité de différencier authz et authn).</p>
<h2>Identification : <a href="https://larlet.fr/david/biologeek/archives/20070104-comment-utiliser-openid-la-solution-d-identification-tant-attendue/">OpenID</a></h2>
<p>Dans le cadre d'OpenID, l'identification permet uniquement de dire : <strong>cette URL est à moi et peut me représenter</strong>. Les providers proposent maintenant d'autres services mais la base c'est uniquement ça, aucune couche de confiance si ce n'est l'assurance d'avoir une URL derrière. Après si vous liez votre OpenID à <a href="http://david.larlet.fr/">votre page personnelle</a>, vous ajoutez forcément un certain crédit à votre OpenID car vous garantissez l'appartenance de la page en question.</p>
<p>Il y a aussi des <a href="http://myid.is">initiatives</a> pour ajouter cette couche de confiance auprès de tiers dits de confiance (Etat, banques, etc) mais c'est une autre histoire.</p>
<h2>Autorisation : <a href="https://larlet.fr/david/biologeek/archives/20080713-decouvrons-oauth-avec-mixin-et-django-oauth/">OAuth</a></h2>
<p>L'autorisation consiste à <strong>laisser l'accès ou pas à une donnée</strong>, que ce soit avec des tokens (comme OAuth), avec des URLs cachées, bref ce que vous voulez en fonction de la criticité de la donnée en question.</p>
<p>Aucune notion d'identité derrière ça, du moment qu'il a les clés on le laisse passer.</p>
<p>Ici aussi, il y a <a href="https://larlet.fr/david/biologeek/archives/20080716-combiner-openid-et-oauth/">des initiatives pour combiner l'autorisation et l'identification</a>, reste à voir comment prendre en compte l'ergonomie au passage.</p>
<h2>Authentification : comptes utilisateurs</h2>
<p><strong>L'authentification cumule l'identification et l'autorisation</strong> pour un service donné, ça correspond bien souvent aux comptes utilisateurs qui définissent qui peut faire quoi sur un service. Lorsque vous vous authentifiez sur un service, vous prouvez que vous êtes la personne qui s'est préalablement enregistrée, la confiance est donc accordée par le service en question (elle peut se baser sur la vérification d'un email par exemple).</p>
<p><strong>OpenID et OAuth peuvent faire partie intégrante d'un compte utilisateur</strong> comme cela est le cas pour <a href="http://www.mixin.com/users/david/">mixin</a>.</p>
<p>Le cas d'OpenID est un peu particulier en fait car les providers ont évolué et cette solution d'identification est maintenant bien souvent associée à une certaine confiance qui permet l'authentification (selon la confiance qu'accorde le service au provider). Le spam progresse forcément aussi dans cette voie donc on va probablement aller vers des whitelists de providers ce qui est complètement contraire à l'idée initiale de décentralisation du protocole mais bon <a href="http://simonwillison.net/2008/Jun/24/openid/">certains semblent s'en réjouir</a>. Allez comprendre.</p>
<p>Il n'y a pas de solution d'authentification globale à ma connaissance (enfin si on fait la somme des comptes Google + Yahoo on devrait s'en approcher...) et c'est pas plus mal compte tenu du pouvoir associé.</p>
<h2>Et MicroID dans tout ça ?</h2>
<p>Comme son nom l'indique, on parle ici d'identification et non de micro-authentification comme le laisse présager le titre du billet initial.</p>
<p>Si on lit <a href="http://microid.org/draft-miller-microid-01.html#overview">la spec</a>, les buts sont clairement identifiés :</p>
<blockquote>
<p>MicroID is a lightweight identity technology that enables the creation of a portable identity token from any two Uniform Resource Identifiers [URI].</p>
<p>Such identity tokens are desirable because they:</p>
<ul>
<li>Enable individuals to assert ownership over information published and reputation earned on the Internet in a granular manner.</li>
<li>Enable service providers to "stamp" information and reputation based on a validated URI associated with an individual who uses the service.</li>
</ul>
</blockquote>
<p>Si on commence par l'<strong>appartenance</strong>, si le hash est public (et c'est ce qui a l'air d'être mis en avant en le mettant dans la source de son site), cela n'a pas vraiment de valeur car (presque) tout le monde peut venir le récupérer pour l'utiliser ailleurs, au même titre qu'un pseudo/email/lien actuel.</p>
<p>S'il est privé, ça ne sert pas à grand chose non plus car il n'y a aucun moyen de vérifier à partir du hash.</p>
<p>Passons maintenant à l'aspect <strong>réputation</strong>, je ne vois pas non plus l'intérêt compte tenu du fait qu'il est impossible d'identifier la personne soumettant le contenu...</p>
<p>La seule solution possible que je vois c'est d'avoir un générateur par service qui ajoute son grain de sel et qui permet de vérifier que l'utilisateur est celui qu'il prétend être mais la simplicité en prend un sacré coup.</p>
<p>Au final, je ne vois pas vraiment l'intérêt de ce nouveau standard qui essaye manifestement de faire plus simple qu'OpenID mais là ça devient <em>trop</em> simple ! J'espère me tromper car je vois mal comment on peut investir autant de temps là-dedans + avoir des consommateurs aussi importants que digg ou plaxo, n'hésitez pas à éclairer ma microlanterne :-).</p>
      </div>
    </article>
    <footer>
      <h6 property="schema:datePublished">— 16/07/2008</h6>
    </footer>
  </section>
  <section>
    <div>
      <h3>Articles peut-être en rapport</h3>
      <ul>
        <li><a href="/david/biologeek/archives/20090125-mieux-communiquer-sur-openid-et-oauth/" title="Accès à Mieux communiquer sur OpenID et OAuth">Mieux communiquer sur OpenID et OAuth</a></li>
        <li><a href="/david/biologeek/archives/20081015-design-centre-sur-activite-et-sur-attention/" title="Accès à Design centré sur l&#39;activité ET sur l&#39;attention">Design centré sur l&#39;activité ET sur l&#39;attention</a></li>
        <li><a href="/david/biologeek/archives/20080713-decouvrons-oauth-avec-mixin-et-django-oauth/" title="Accès à ★ Découvrons OAuth avec mixin (et django-oauth)">★ Découvrons OAuth avec mixin (et django-oauth)</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">neolao</span> le <span class="comment-date" property="schema:commentTime">16/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>J&#39;ai pensé exactement à la même chose quand j&#39;ai lu ce que faisait microID ...</p>

<p>Ca sert à rien.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Kevin</span> le <span class="comment-date" property="schema:commentTime">16/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>En parlant d&#39;OpenID, voilà un nouveau prestataire : LiquidID. Il offre la possibilité de créer un alias e-mail et de servir ainsi de filtre anti-spam. À voir.</p>

<p><a href="http://www.readwriteweb.com/archives/liquidid_openid_email_aliasing.php">http://www.readwriteweb.com/archives/liquidid_openid_email_aliasing.php</a></p>

<p>Sachant que GMail, à défaut d&#39;être totalement privé (mais qu&#39;ai-je à cacher ?), me bloque près de 1500 spams par mois, ce qui m&#39;en laisse un ou deux passer chaque mois alors que je publie mon adresse e-mail sans tabou ni <a href="mailto:prénomRETIREZMOI@ANTISPAMnomdefamille.com">prénomRETIREZMOI@ANTISPAMnomdefamille.com</a> :-)</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Eric</span> le <span class="comment-date" property="schema:commentTime">16/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Sisi, l&#39;appartenance fonctionne sous MicroID, mais c&#39;est du déclaratif, pas de la certification.</p>

<p>Tu sais juste que le propriétaire du Site XX affirme être propriétaire de l&#39;adresse email YY. Tu ne sais pas si effectivement c&#39;est vrai, par contre tu sais désormais que chaque fois que tu as le site XX en référence, tu peux rediriger les emails ou l&#39;adresse de contact vers YY.</p>

<p>De même, si dans un email de YY le correspondant affirme être l&#39;auteur ou la personne référencée par le site XX, tu peux le vérifier. Si son email est correctement mise en microID sur le site XX, tu peux être sûr que c&#39;est vrai (ou alors il a trouvé une faille de sécurité sur XX).</p>

<p>C&#39;est souvent suffisant pour pas mal de choses.</p>

<p>Pour le whitelisting de providers openid peut être intelligent si c&#39;est fait correctement, c&#39;est à dire si les autres sont sur liste grise. Il s&#39;agit alors juste de dire &quot;je sais que le provider X fait son boulot pour bannir les robots et spammers de son réseau donc je vais publier immédiatement les commentaires de ses utilisateurs, les autres passeront la modération&quot;. C&#39;est ce qui est fait à deux ou trois endroits.<br />Si c&#39;est pour bannir les providers tiers comme HealthVault c&#39;est effectivement crétin.</p>

<p>Sinon pour ajouter un minimum de couche de confiance anti-spam à openid j&#39;avais trouvé l&#39;idée de <a href="http://botbouncer.com/">http://botbouncer.com/</a> très bonne. Ca manque de quelques détails : genre que le service mette à jour leur test anti-robot régulièrement et qu&#39;on puisse dire &quot;je veux les utilisateurs qui ont passé le test 26 ou plus récent&quot; (parce que sinon dès que leur test anti-robot sera cassé c&#39;est tout le service qui devient inutile.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">giz404</span> le <span class="comment-date" property="schema:commentTime">16/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>J&#39;étais justement en train d&#39;essayer de comprendre à quoi MicroID pouvait servir... Finalement, ça ne sert pas à grand chose... En fait, c&#39;est juste une sorte de microformat &quot;unifié&quot;, qui permettrait de rattacher des infos à une personne sans se prendre la tête (sans aucune considération de sécurité, d&#39;authentification ou de de notion d&#39;info public/privée.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Thesa</span> le <span class="comment-date" property="schema:commentTime">16/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@Eric :</p>

<p>&gt; Pour le whitelisting de providers openid peut être intelligent si c&#39;est fait correctement, c&#39;est à dire si les autres sont sur liste grise.</p>

<p>Et mon PHPMyOpenID installé sur mon serveur, tu crois que j&#39;ai des chances de le voir passer en liste blanche ? Parce que rester en liste grise ad-vitam æternam, non merci...</p>

<p>Franchement, si l&#39;OpenID finit comme le mail, je trouverai ça catastrophique pour Internet...</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">16/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>&quot;L&#39;authentification cumule l&#39;identification et l&#39;autorisation pour un service donné&quot;</p>

<p>Moui. Faut vouloir le dire vite. Par exemple, mon commentaire, celui-là. Qui est-ce qui l&#39;a écrit ? C&#39;est moi, le même moi qui fait habituellement des pâtés mal relus. Cette opération d&#39;association d&#39;un document à un autre, en disant que c&#39;est le même auteur,  c&#39;est ça l&#39;identification.</p>

<p>Après vient le problème du travestissement, des fausses déclarations, il faut authentifier cette identité.</p>

<p>Ici on m&#39;identifie comme &quot;Damien B&quot;, et ailleurs, d&#39;autres &quot;Damien B&quot; oeuvrent, est-ce que ces &quot;Damien B&quot; déclarent être la même identité ? Est-ce que ces déclarations sont authentiques ?</p>

<p>Le nom OpenID est trompeur, puisque qu&#39;il mixe une manière d&#39;identifier une personne (par une URL) et une manière d&#39;authentifier cette identité (par le protocole OpenID). D&#39;ailleurs, ils utilisent bien ce vocabulaire dans leur page de glossaire : <a href="http://openid.net/specs/openid-authentication-2_0.html#terminology">http://openid.net/specs/openid-authentication-2_0.html#terminology</a> .</p>

<p>Le nom OAuth est mal choisi, car la chaîne &quot;auth&quot; n&#39;est pas discriminante entre authorization et authentication. Et d&#39;ailleurs, ils entretiennent cette confusion : sur la page d&#39;accueil &quot;An open protocol to allow secure API authentication&quot;, dans la spéc&quot;. Parce qu&#39;en fait, OAuth n&#39;est pas un système de droits comme on l&#39;entend de manière générale (ACL ou flags). Car qui gère les autorisations dans OAuth ? C&#39;est le Service Provider. Comment les gère-t-il ? Comme il veut. En fait, OAuth est uniquement un système d&#39;authentification. C&#39;est l&#39;utilisateur qui vient authentifier que le Consumer est bien celui qu&#39;il prétend être, et après le Service Provider décide ou non de laisser le Consumer accéder à la ressource, mais cette décision est hors du cadre de OAuth.</p>

<p>Alors comment désigner un système complet identité/authentification/autorisations ? En fait le problème existe peu, car un tel système complet indique une idée de centralisation, hors, la course est effectivement à la décentralisation (et l&#39;a toujours été, les SSO ne gèrent quasiment jamais la partie autorisation, avec en exception notable Active Directory qui propose un tout en un, mais que serait Microsoft s&#39;il ne proposait pas un système centralisé ?).</p>

<p>Alors que fait MicroID ? De l&#39;identification, point barre. Et de l&#39;identification sans authentification, à quoi ça sert sur le web ? Ca sert à tout, vu que c&#39;est ce qu&#39;on fait tous les jours en laissant un nom ! Bref, MicroID, c&#39;est de la branlette de µformateux (promis, c&#39;est de la dernière fois que je suis vulgaire ici).</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">17/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@neolao : au moins ton avis est clair.</p>

<p>@Kevin : je ne connaissais pas LiquidID mais ça rejoint tout à fait le type de service qui peut graviter autour d&#39;OpenID.</p>

<p>@Eric :</p>

<p>&gt; C&#39;est souvent suffisant pour pas mal de choses.</p>

<p>En fait c&#39;est là où ça coince, je ne vois pas dans quelles utilisations c&#39;est plus pertinent (en terme de simplicité) qu&#39;OpenID, ça suffirait pour quoi concrètement ?</p>

<p>Je ne connaissais pas botbouncer, merci.</p>

<p>@giz404 : oui j&#39;ai vu ton commentaire juste avant de poster le billet. Si ça se trouve c&#39;est juste une collecte d&#39;emails déguisée... demain je lance un CardID qui crée un hash à partir de votre numéro de carte bleue ! ;-)</p>

<p>@Thesa : et oui, bienvenue dans un monde basé sur le pouvoir.</p>

<p>@Damien B. :</p>

<p>&gt; Moui. Faut vouloir le dire vite.</p>

<p>J&#39;aime bien te tendre des perches dans mes billets :-).</p>

<p>Je suis d&#39;accord sur OpenID, il faut différencier le but et le protocole.</p>

<p>Concernant OAuth, je t&#39;invite à lire ce thread récent <a href="http://groups.google.com/group/oauth/browse_thread/thread/d8ec85782c46c23f">http://groups.google.com/group/oauth/browse_thread/thread/d8ec85782c46c23f</a></p>

<p>Effectivement, je suis d&#39;accord sur le fait que l&#39;autorisation est laissée au provider mais si l&#39;on se place du point de vue utilisateur, il autorise bien l&#39;accès à une ressource (après s&#39;être authentifié, ce qui en fait une combinaison des deux, soit).</p>

<p>Ta conclusion me fait penser à ce qui s&#39;est passé avec XFN et FOAF... rien de bon pour l&#39;utilisateur (et encore moins pour le développeur).</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">17/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>&quot;Je suis d&#39;accord sur OpenID, il faut différencier le but et le protocole.&quot;</p>

<p>L&#39;identification n&#39;est pas un but, c&#39;est juste que c&#39;est par nature déclaratif. Par exemple, si on me croise dans la rue, je serais identifié en tant que &quot;le gros mal rasé avec des boutons bizarres autour des yeux&quot;. Mais plusieurs individus peuvent correspondre à cette identité déclarative, seule le processus d&#39;authentification (&quot;étiez vous le gros mal rasé à 10h jeudi dernier place de l&#39;Eglise ?&quot;) permet de faire quelque chose de validé avec cette identité.</p>

<p>&quot;Concernant OAuth, je t&#39;invite à lire ce thread récent&quot;</p>

<p>Oh ben oui, que des participants au projet, ça va être objectif :-)<br />Lisons une page liée dans ce fil :<br />&quot;OAuth offers safe delegation of authority.  It allows you to authorize a service (the Consumer) to act on the your behalf at a second service (the Service Provider) -- but only within limits set by the you and the Service Provider.&quot; (fautes d&#39;origine)</p>

<p>C&#39;est la partie &quot;limits set by the you and the Service Provider&quot;. Dans OAuth, il n&#39;y a *aucune* notion de gestion de droits. A savoir, comment un Consumer sait s&#39;il a le droit d&#39;accéder à telle ou telle ressource dans OAuth ?<br />Réponse 1 : échange de paramètres supplémentaires, spécifiques au Service Provider (car notion non codifiée dans OAuth)<br />Réponse 2 : il y va avec son jeton d&#39;accès au fusil, et ça passe ou ça casse</p>

<p>Exemple concret d&#39;utilisation d&#39;une gestion simple des droits simple : droit lecture, droit écriture dans mixin.<br />Imaginons que je fasse un widget pour Mixin, mais que pour une raison X ou Y, je ne veuille pas que ce widget pour moi utilisateur authentifié utilisant ce widget, ait le droit de modifier mes données. Mais je veux quand même qu&#39;il les lise.<br />On repart de ton post :</p>

<p>&quot;Initialisation&quot; =&gt; pas de notions de droits, c&#39;est du tout ou rien</p>

<p>&quot;Interaction&quot; <br />&quot;Un autre avantage qui n&#39;a pas été mis en pratique afin de faciliter le cheminement de l&#39;utilisateur est de pouvoir limiter l&#39;accès à certaines ressources, voire de régler finement le type d&#39;accès (lecture/écriture).&quot;</p>

<p>Avantage apporté par quoi ? Qui serait implémenté à quel niveau ? Est-ce que le widget peut connaître les droits de manière normalisée par le protocole normal OAuth ? Si oui, alors on peut parler d&#39;une début de gestion de droits *au niveau de OAuth*. Si non, c&#39;est juste une gestion de droits *spécifique* que tu appliques à un utilisateur (au sens Use Case) qui se trouvé avoir été authentifié par OAuth.</p>

<p>&quot;mais si l&#39;on se place du point de vue utilisateur, il autorise bien l&#39;accès à une ressource (après s&#39;être authentifié, ce qui en fait une combinaison des deux, soit).&quot;</p>

<p>Si l&#39;on se place du point de vue utilisateur final, l&#39;utilisateur autorise l&#39;accès à une ou des ressources. Mais l&#39;autorisation en elle-même n&#39;a pas grand chose à voir avec OAuth, il a surtout authentifié (CNRTL : &quot;Attester, certifier le caractère authentique de quelque chose ou de quelqu&#39;un.&quot;) que c&#39;était bien *lui-même* qui venait avec ce client externe *là*, taper dans ses données hébergées par le Service Provider. La partie gestion des droits étant complètement orthogonale dans OAuth une fois que le Consumer a eu son jeton d&#39;accès.</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">17/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@Damien B:</p>

<p>&gt; L&#39;identification n&#39;est pas un but</p>

<p>En effet, je voulais parler de l&#39;objectif qui est la déclaration d&#39;identité mais j&#39;ai pas trouvé le bon terme.</p>

<p>&gt; A savoir, comment un Consumer sait s&#39;il a le droit d&#39;accéder à telle ou telle ressource dans OAuth ?</p>

<p>Dans mon implémentation, j&#39;ai ajouté le paramètre &#39;scope&#39; pour désigner la ressource considérée mais ce n&#39;est pas standard (même si Google l&#39;a fait aussi), il me semble que c&#39;est plutôt la solution 2 qui a été pensée à l&#39;origine. Espérons que tout ça soit normalisé dans une future version.</p>

<p>&gt; Avantage apporté par quoi ? Qui serait implémenté à quel niveau ? Est-ce que le widget peut connaître les droits de manière normalisée par le protocole normal OAuth ?</p>

<p>Bon je me rends compte que j&#39;ai peut-être pas été très clair sur cette partie et qu&#39;il faut différencier la spécification de mon implémentation.</p>

<p>Concernant django-oauth, tu peux laisser le choix à l&#39;utilisateur lors de l&#39;initialisation de spécifier la ressource considérée et si elle est accessible en lecture/écriture (ce n&#39;est pas utilisé dans mixin mais c&#39;est générique dans la lib).</p>

<p>En revanche la spécification ne mentionne/normalise pas ces problématiques (d&#39;où la partie limites de mon précédent billet).</p>

<p>&gt; La partie gestion des droits étant complètement orthogonale dans OAuth une fois que le Consumer a eu son jeton d&#39;accès.</p>

<p>Pas exactement car selon l&#39;implémentation un jeton peut être dédié à une ressource et/ou à un droit. C&#39;est le moment où une spec trop limitée est à l&#39;origine d&#39;extensions et d&#39;innovations de la part des devs qui sont ensuite réintégrées dans la spec. L&#39;éternel lombric théorie/pratique avançant par à coups.</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">17/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>&gt; &gt; La partie gestion des droits étant complètement orthogonale dans OAuth une fois que le Consumer a eu son jeton d&#39;accès.<br />&gt; Pas exactement car selon l&#39;implémentation un jeton peut être dédié à une ressource et/ou à un droit.</p>

<p>Donc IRC et le web ne sont pas orthogonaux, parce que selon l&#39;implémentation, tu peux avoir un  navigateur web qui est client IRC. C&#39;est la non-orthogonalité 2.0 :-) Parce que selon l&#39;implémentation, ça veut dire selon le Service Provider, on retourne à la case départ :-)</p>

<p>&gt; C&#39;est le moment où une spec trop limitée est à l&#39;origine d&#39;extensions et d&#39;innovations de la part des devs qui sont ensuite réintégrées dans la spec.</p>

<p>Ah, &quot;innovation&quot;, c&#39;est donc ça le secret. Regardons la mailing list (je ne trouve pas de brouillon de la spéc en ligne)... qu&#39;est ce qu&#39;on va trouver dans les Common Extensions :<br />&quot;Session extension – Add a workflow allowing Service Providers to limit the lifetime and resources of Access Tokens and provide a method for Consumers to request to extend those limitations. The session extension will address two use cases: add additional rights to an existing Access Token, and extend the lifetime of an Access Token if the End User authorized a longer period than allocated for the token.&quot;</p>

<p>Ajouter des droits à un jeton d&#39;accès existant. D&#39;où vient cette notion de droits ?</p>

<p>Septembre 2007 :<br />&quot;By itself, OAuth does not provide any method for scoping the access rights granted to a Consumer.  A Consumer either has access to <br />Protected Resources or it doesn&#39;t.&quot;</p>

<p>OAuth 2008.1 Core =&gt; pas de texte en ligne</p>

<p>Qu&#39;est ce qu&#39;on a d&#39;autre... OpenFile</p>

<p>&quot;The OpenFile idea is essentially the combination of: <br />  OAuth/Core + OAuth/Rights (TBD) + OAuth/Discovery + GrantedResources (represented as an Atom feed and an OAuth Protected <br />Resource)</p>

<p>It has been difficult to decide what form this idea should be in. Currently the rights and granted resources &quot;resource&quot; are the new <br />elements and have been combined into the OpenFile spec, although I recognize that these are orthogonal components.  We&#39;ve decided to put all these elements together to attempt to provide a single spec that <br />someone could implement against to support the intended use cases.  It may be valid and important to separate the two, or not; your opinions will help in this.&quot;</p>

<p>Tiens, lui a un concept d&#39;othogonalité très 1.0. Et encore une proposition pour réinventer WebDAV. Bon. Ca fleure bon le NIH quand même OAuth et la gestion des droits... Dans l&#39;attente d&#39;avoir des liens un poil plus convainquants (ou un papelard révolutionnaire du MIT :-) ), veuillez agréer monsieur blablabla. Et bonne nuit si tu es encore debout.</p>

<p>C&#39;est pas mal ce système de mail en fin de compte. Dommage qu&#39;il n&#39;y ait pas de copie dans une quelconque boîte &quot;courrier envoyé&quot;. Ca s&#39;appelait comment déjà ce truc ? Cocomm.. ??</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Eric</span> le <span class="comment-date" property="schema:commentTime">17/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@Thesa: ah mais il ne s&#39;agit pas de te mettre en liste grise. Il s&#39;agit de t&#39;y laisser. Ce que je veux dire c&#39;est que avoir un provider connu est sérieux est un moyen (supplémentaire) de s&#39;assurer que tu n&#39;es pas un robot/spammeur.</p>

<p>Il est donc logique qu&#39;on te mette plus facilement sur liste blanche. C&#39;est un point &quot;en plus&quot; pour ceux qui utilisent ces providers. Ce n&#39;est pas un point &quot;en moins&quot; pour les autres.</p>

<p>Après si ça te gave de ne pas être white-list sur ton propre serveur openid à toi de proposer un truc qui permet de différencier les robots des utilisateurs et qui fonctionne pour toi. D&#39;autres s&#39;y sont essayés et ce n&#39;est pas si simple. Donc à défaut, proposer au moins une white-list pour ceux dont on sait qu&#39;ils sont clean (parce que d&#39;un provider sérieux qui fait son boulot sur le sujet), je me vois mal leur reprocher.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">webtik</span> le <span class="comment-date" property="schema:commentTime">18/12/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@David et comme le disait justement @Damien juste pour rajouter quelques choses à cela...</p>

<p>l&#39;identification est ce que je suis - vérification 1 parmi N<br />On ne vérifie pas OpenID de cette manière donc authentification pour moi...</p>

<p>l&#39;authentification est ce qui prouve ce que je suis (ce que je possède... un couple login/password, une carte à puce ... par exemple) vérification 1/1 OpenID authentification cadre à cela pour moi...</p>

<p>Mais si quelqu&#39;un peut me l&#39;expliquer différemment je suis preneur ;)</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>