Je suis en train de construire une application web basée sur Pylons avec une API RESTful, qui manque actuellement d'authentification. Je vais donc l'implémenter et afin d'éviter tous les problèmes et les précautions liés au stockage des mots de passe des utilisateurs, j'aimerais utiliser OpenID pour l'authentification. Quelle serait la meilleure façon de procéder ? Ces deux éléments sont-ils compatibles ? Existe-t-il des API REST existantes qui utilisent OpenID et dont je peux m'inspirer ?
Réponses
Trop de publicités?J'ai maintenant passé un certain temps à rechercher les options et je voudrais résumer les résultats. Tout d'abord, un peu plus de contexte - je développe et contrôle à la fois le service et le consommateur de l'API. Le consommateur est une application Flash qui est servie par le même hôte que l'API et qui est censée être utilisée dans le navigateur. Aucun client tiers en vue pour le moment.
La question peut donc être divisée en deux parties,
- Comment faire l'authentification OpenID via l'API ?
- comment maintenir l'état "authentifié" dans les demandes ultérieures ?
Pour la première partie, l'authentification OpenID comprend presque toujours des étapes interactives. Au cours du processus d'authentification, il y aura très probablement une étape où l'utilisateur se trouvera sur la page Web du fournisseur OpenID, où il s'identifiera et appuiera sur un bouton "J'accepte". L'API ne peut et ne doit pas gérer cela de manière transparente (pas de "dites-moi votre fournisseur OpenID et votre mot de passe et je m'occupe du reste"). Le mieux qu'elle puisse faire est de transmettre des liens HTTP aller et retour que le client doit ouvrir et suivre les instructions.
Maintien de l'état "authentifié
Les API REST devraient être apatrides, chaque demande devrait inclure toutes les informations nécessaires pour la traiter, non ? Cela n'aurait aucun sens de s'authentifier auprès du fournisseur OpenID pour chaque requête, donc un peu de Ce type de session est nécessaire. Voici quelques-unes des options de communication de la clé de session (ou "jeton d'accès" ou nom d'utilisateur/mot de passe) :
- HTTPS + authentification BASIC (en-tête "Authorization : Basic ..." dans chaque requête)
- Demandes de signature Style Amazon (En-tête "Authorization : AWS ... " dans chaque requête)
- OAuth : acquérir un jeton d'accès, l'inclure, ainsi qu'un tas d'autres paramètres, dans chaque requête.
- Cookie qui stocke la clé de session (en-tête "Cookie : ... " dans chaque requête)
- Cookie signé qui stocke les informations de session dans le cookie lui-même.
Il n'y a qu'un seul consommateur d'API pour l'instant, alors j'ai choisi d'opter pour la chose la plus simple qui puisse fonctionner : les cookies. Ils sont super faciles à utiliser dans Pylons, avec l'aide de Bécher . Ils fonctionnent également dans l'application Flash - puisqu'elle s'exécute à l'intérieur du navigateur, celui-ci inclura les cookies pertinents dans les requêtes de l'application Flash - l'application n'a pas besoin d'être modifiée du tout à cet égard. Voici une question de StackOverflow qui préconise également l'utilisation de cookies : Authentification RESTful pour les applications web
Beaker a également la particularité de sessions avec cookies uniquement où toutes les données de session sont contenues dans le cookie lui-même. Je suppose que c'est à peu près tout ce qu'il y a d'apatride. Il y a no magasin de session sur le serveur. Les cookies sont signés et éventuellement cryptés pour éviter qu'ils ne soient altérés du côté client. L'inconvénient est que le cookie devient un peu plus gros, puisqu'il doit maintenant stocker plus que la clé de session. En supprimant certains éléments dont je n'avais pas vraiment besoin dans la session (restes de l'authentification OpenID), j'ai pu réduire la taille du cookie à environ 200 octets.
OAuth est mieux adapté à l'utilisation de l'API. Voici un exemple d'utilisation d'OAuth en Python : oauth-python-twitter . Leah Culver's python-oauth est l'implémentation canonique d'OAuth en Python, mais la bibliothèque python-oauth2 est un candidat récent qui fait parler de lui. Quant à l'inspiration, django-piston prend en charge l'utilisation d'OAuth pour l'authentification lors de la création d'API RESTful pour Django, bien que la documentation ne soit pas aussi agréable que je le souhaiterais pour ce sujet particulier.