davidbgk
/
larlet-fr-david


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169
							<!doctype html>
<html lang=fr>
<head>
  <!-- Always define the charset before the title -->
  <meta charset=utf-8>
  <title>★ Découvrons OAuth avec mixin (et django-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/20080713-decouvrons-oauth-avec-mixin-et-django-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">★ Découvrons OAuth avec mixin (et django-oauth)</h1>
    <article typeof="schema:BlogPosting">
      <div property="schema:articleBody">
        <img src="/static/david/biologeek/images/logos/oauth.png" alt="vignette" style="float:left; margin: 0.5em 1em;" property="schema:thumbnailUrl" />
        <p>Après <a href="http://sunfox.org/blog/2008/06/26/donnez-moi-vos-mots-de-passe/">le billet de Sunny</a>, on a décidé avec <a href="http://www.mixin.com">mixin</a> d'utiliser <a href="http://oauth.net">OAuth</a> pour autoriser l'accès aux données privées de l'API. Rien n'avait encore été fait avec Django alors c'était l'occasion de faire une application réutilisable : <a href="http://code.larlet.fr/django-oauth/">django-oauth</a>.</p>
<h2>Avez-vous les clefs ?</h2>
<p>À première vue, le diagramme peut sembler assez complexe :</p>
<p>
    <img
        src="/static/david/biologeek/images/oauth_flow_diagram.png"
        alt="OAuth flow diagram"
        style="margin: 0pt auto; display: block;"/>
</p>

<p>Rassurez-vous, l'utilisateur ne suit que les flèche en trait plein, ce qui constitue tout de même un aller-retour entre le service souhaitant accéder aux données (Consumer) et celui hébergeant les données (Provider).</p>
<p>Prenons un exemple simple et d'actualité : <strong>vous souhaitez développer un widget qui permette de créer/consulter/éditer des événements sur mixin</strong>.</p>
<p>Il faut distinguer deux étapes :</p>
<ul>
<li>l'initialisation : le moment où l'utilisateur donne l'accès à ses données</li>
<li>l'interaction : la manipulation des données par le service grâce à cet accès</li>
</ul>
<h3>Initialisation</h3>
<p>Avant toute chose, il faut créer un accès consumer pour votre widget à partir de la partie Développeurs des paramètres de votre profil mixin. Ces informations vont vous permettre d'effectuer des requêtes signées de votre service vers mixin.</p>
<p>Grâce à vos identifiants, vous allez pouvoir récupérer des tokens de requête lorsqu'un utilisateur souhaite procéder à une autorisation d'accès, cette opération se fait de serveur à serveur et ne requiert pas d'action de la part de l'utilisateur.</p>
<p>Avec ce token de requête vous pouvez maintenant rediriger l'utilisateur sur mixin qui va être confronté à une question existentielle : voulez-vous autoriser l'accès à vos ressources personnelles ? Si oui, le token de requête est validé et l'utilisateur est redirigé vers le service, si non, l'utilisateur est redirigé sur le service.</p>
<p>Le service va finalement échanger son token de requête, limité en temps, avec un token d'accès. Ce dernier n'est délivré que si le token de requête a été validé préalablement par l'utilisateur bien entendu.</p>
<h3>Interaction</h3>
<p>Une fois ce token d'accès en sa possession, le service va pouvoir interagir avec l'API RESTful de mixin en transmettant les arguments relatifs au token.</p>
<p>Ces actions ne requièrent aucune action supplémentaire de la part de l'utilisateur (bon ok ça dépend de votre widget, sinon ça perd son intérêt...).</p>
<p>Le gros avantage d'OAuth, c'est qu'il n'est pas nécessaire de donner son mot de passe et vous pouvez à tout moment supprimer l'accès à un service tiers depuis mixin sans impacter les autres services accédant à vos données.</p>
<p>Un autre avantage qui n'a pas été mis en pratique afin de faciliter le cheminement de l'utilisateur est de pouvoir limiter l'accès à certaines ressources, voire de régler finement le type d'accès (lecture/écriture).</p>
<h2>Utilisation avec Django</h2>
<p>Pour l'instant seule la partie Provider a été rendue publique, elle permet de gérer les consumers, les tokens, les resources et les nonces. Vous pouvez directement consulter la <a href="http://code.larlet.fr/doc/django-oauth-provider.html">documentation de django-oauth provider</a> qui constitue aussi les tests dans la plus pure tradition python.</p>
<p>Il vous suffit d'ajouter l'application dans vos settings et de lancer un syncdb. La vue à afficher à l'utilisateur est personnalisable en spécifiant le setting <em>OAUTH_AUTHORIZE_VIEW</em>, normalement tout est bien documenté donc je ne vais pas me répéter, n'hésitez pas à demander au besoin, il y a un exemple détaillé présent du le dépôt.</p>
<h2>Limites inévitables</h2>
<h3>Complexité</h3>
<p>Il m'a fallu un bon moment pour comprendre le protocole, même si maintenant ça me semble évident c'est toujours rebutant d'avoir à passer du temps là-dessus. Bon d'un autre côté c'est aussi ce qui est intéressant, aller explorer des contrées inconnues, ça dépend de votre point de vue :-).</p>
<h3>Ergonomie</h3>
<p>L'aller-retour entre les deux sites peut destabiliser l'utilisateur qui se demande pourquoi ces étapes sont nécessaires. Le problème est le même avec OpenID, mais je préfère que ce cheminement soit généralisé au lieu de donner son mot de passe à tout va !</p>
<h3>Phishing</h3>
<p>Dès qu'il y a redirection, il est possible de faire du phishing très facilement : vous redirigez sur une page de login du site distant hébergée sur votre serveur pour récupérer les identifiants/mot de passe. Il y a du boulot de ce côté là...</p>
<h3>Maturité</h3>
<p>Le protocole souffre de certaines erreurs de jeunesse, il est par exemple assez hallucinant qu'il n'y ait rien de standardisé au niveau de la gestion des erreurs, de la langue de l'utilisateur ou de la ressource à laquelle souhaite accéder le service ! Heureusement, certaines de ces limites seront corrigées dans la prochaine version d'OAuth.</p>
<h2>Conclusion</h2>
<p>Au final, c'est une bonne avancée (on ne demande plus le mot de passe à l'utilisateur) mais elle se fait pour l'instant au détriment d'une certaine simplicité apparente due aux mauvaises habitudes enseignées aux utilisateurs et c'est bien dommage. C'est un peu comme envoyer un code par email, c'est pratique lorsqu'on sait que <a href="http://www.typhon.com">son provider</a> et son accès sont sécurisés mais ça concerne une minorité d'internautes et ça laisse une faille de sécurité énorme par ailleurs...</p>
<p>Pownce.app est la <a href="http://factoryjoe.com/blog/2008/07/11/oauth-for-the-iphone-pownceapp/">première application pour iPhone à utiliser OAuth</a> à ma connaissance, ce qui est logique compte tenu de l'implication de <a href="http://leahculver.com/">Leah Culver</a> (elle a écrit la lib Python et une partie de la spec) mais c'est toujours intéressant de voir une utilisation combinant mobile+web. Google aussi a beaucoup investi dans ce protocole et leurs <a href="http://sites.google.com/site/oauthgoog/">réflexions sur OAuth et les interactions possibles</a> sont vraiment pertinentes.</p>
<p>Maintenant que mixin dispose d'une API, il ne reste plus qu'à s'en servir ! Outre le site internet, mixin devient vraiment intéressant avec toutes les applications qui gravitent autour et les interactions avec les autres services. Certaines intégrations sont en préparation mais vous pouvez devenir acteur et <a href="http://dev.mixin.com">développer votre propre outil</a>. N'hésitez pas à me contacter si vous souhaitez développer quelque chose ou si vous avez des soucis avec OAuth, les idées révolutionnaires sont les bienvenues aussi ;-).</p>
      </div>
    </article>
    <footer>
      <h6 property="schema:datePublished">— 13/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/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">Sunny</span> le <span class="comment-date" property="schema:commentTime">13/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Merci, ça donne envie de comprendre OAuth :) J&#39;adorerais mettre les mains dans le camboui avec une idée d&#39;application à connecter à Mixin.</p>

<p>La suite logique pour Mixin est de ne plus utiliser Plaxo qui demande un mot de passe pour importer les contacts ? ;)</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Eric Florenzano</span> le <span class="comment-date" property="schema:commentTime">13/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Il y a un petit probleme avec le lien a mixin.  C&#39;est qu&#39;il y a 4 w&#39;s comme &#39;wwww&#39;.</p>

<p>Mais merci beaucoup pour le post, c&#39;est tres interessant.  (Et je suis desolee parce que je sais que ma francais n&#39;est pas bien du tout, hehe)</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">14/07/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@Sunny : n&#39;hésite surtout pas ! Tu sais où me trouver :)</p>

<p>Pour plaxo effectivement c&#39;est la prochaine étape, ça serait bien qu&#39;ils s&#39;y mettent d&#39;eux-même...</p>

<p>@Eric Florenzano : Merci pour l&#39;effort de français ! Le lien est corrigé.</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>