davidbgk
/
larlet-fr-david

title:      ★ Découvrons OAuth avec mixin (et django-oauth)
slug:       decouvrons-oauth-avec-mixin-et-django-oauth
date:       2008-07-13 00:16:32
type:       post
vignette:   images/logos/oauth.png
contextual_title1:  Mieux communiquer sur OpenID et OAuth
contextual_url1:    20090125-mieux-communiquer-sur-openid-et-oauth
contextual_title2:  ★ Le Web Sémantique ou l&#39;importance des données liées
contextual_url2:    20081117-le-web-semantique-ou-limportance-des-donnees-liees
contextual_title3:  Différences entre identification, autorisation et authentification
contextual_url3:    20080716-differences-entre-identification-autorisation-et-authentification

Après [le billet de Sunny](http://sunfox.org/blog/2008/06/26/donnez-moi-vos-mots-de-passe/), on a décidé avec [mixin](http://www.mixin.com) d'utiliser [OAuth](http://oauth.net) 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 : [django-oauth](http://code.larlet.fr/django-oauth/).

## Avez-vous les clefs ?

À première vue, le diagramme peut sembler assez complexe :

<p>
    <img
        src="/static/david/biologeek/images/oauth_flow_diagram.png"
        alt="OAuth flow diagram"
        style="margin: 0pt auto; display: block;"/>
</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).

Prenons un exemple simple et d'actualité : **vous souhaitez développer un widget qui permette de créer/consulter/éditer des événements sur mixin**.

Il faut distinguer deux étapes :

* l'initialisation : le moment où l'utilisateur donne l'accès à ses données
* l'interaction : la manipulation des données par le service grâce à cet accès


### Initialisation

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.

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.

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.

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.


### Interaction

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.

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

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.

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


## Utilisation avec Django

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 [documentation de django-oauth provider](http://code.larlet.fr/doc/django-oauth-provider.html) qui constitue aussi les tests dans la plus pure tradition python.

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 *OAUTH_AUTHORIZE_VIEW*, 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.


## Limites inévitables

### Complexité

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 :-).

### Ergonomie

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 !

### Phishing

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

### Maturité

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.


## Conclusion

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 [son provider](http://www.typhon.com) 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...

Pownce.app est la [première application pour iPhone à utiliser OAuth](http://factoryjoe.com/blog/2008/07/11/oauth-for-the-iphone-pownceapp/) à ma connaissance, ce qui est logique compte tenu de l'implication de [Leah Culver](http://leahculver.com/) (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 [réflexions sur OAuth et les interactions possibles](http://sites.google.com/site/oauthgoog/) sont vraiment pertinentes.

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 [développer votre propre outil](http://dev.mixin.com). 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 ;-).