2011-09-30 3 views
15

J'ai trouvé pas mal de questions sur ce sujet sur SO, mais n'a pu trouver aucune réponse à cette question:API RESTful authentification

Dois-je valider les utilisateurs avec leur nom d'utilisateur et mot de passe, ou avec une clé API? Et quels sont les avantages et les inconvénients de chaque méthode.

Je pose cette question parce que dans mon API, il y a quelques méthodes que je voudrais verrouiller et vérifier que l'utilisateur a accès à un document ou une action. Je suis un peu réticent à m'authentifier en demandant à l'utilisateur d'envoyer un en-tête HTTP AUTH avec son nom d'utilisateur et son mot de passe car il ne semble pas sécurisé et représente un peu plus de tracas pour l'utilisateur. D'un autre côté, si j'utilise une clé API, à quoi sert-il de créer un mot de passe? Comme ils ne l'utiliseront plus pour accéder aux fonctionnalités de l'API.

MISE À JOUR

Si d'autres lecteurs de ce sont curieux de ce que je fini par utiliser, j'ai décidé de copier comment Amazon fait leur validation (bonne explication here: https://www.ida.liu.se/~TDP024/labs/hmacarticle.pdf)

+2

Appréciez la mise à jour. Je vous remercie. –

+0

Le lien est cassé, merci de bien vouloir le mettre à jour. Lien mis à jour: https://www.ida.liu.se/~TDP024/labs/hmacarticle.pdf –

+0

lien: http://acaasia.blogspot.co.il/2013/04/designing-secure-rest-web- api-without.html – OhadR

Répondre

7

vous pouvez utiliser l'authentification HTTP sur SSL et c'est assez sécurisé. Cependant, cela rend la consommation de l'API un peu difficile car elle nécessite que la bibliothèque client prenne en charge SSL. SSL peut également affecter les performances si vous attendez trop d'appels simultanément.

L'option de clé API est tout aussi peu sûre que l'authentification HTTP sans SSL. Si vous n'êtes pas concerné par la sécurité, API Key est la solution la plus simple pour les utilisateurs de l'API.

+0

Donc, si vous allez sur la route de la clé API, vaut-il la peine que l'utilisateur fasse un mot de passe? On dirait que la clé API se débarrasserait de la plupart sinon la totalité du but d'avoir un mot de passe – Obto

+0

@Obto nom d'utilisateur peut être généré séquentiellement et mot de passe peut être généré de manière aléatoire. Le plus de parties de l'accréditation d'authentification; plus il est long et difficile de déchiffrer le mot de passe. C'est vraiment une question de goût. Une clé API plus longue avec des parties séquentielles et aléatoires ou un nom d'utilisateur séparé et un mot de passe. La clé API n'est généralement pas lisible par l'utilisateur et générée automatiquement (dans ce cas, le mot de passe est redondant). –

+0

Donc, à la fin, il semble que cela se résume à vos propres préférences – Obto

5

Une bonne méthode consiste à avoir une méthode de connexion, en prenant le nom d'utilisateur et mot de passe (espérons sur TLS). Vous leur donnez un jeton d'expiration s'ils réussissent à authentifier; le reste de leurs appels d'API doit contenir ce jeton pour réussir.

+0

@HasanKhan bien clairement oAuth fait quelque chose de mal. – Ivo

+0

@Hasan Khan Notez que le jeton n'a pas besoin d'être stocké dans un état partagé; il pourrait simplement être créé de manière déterministe en utilisant un secret côté serveur (par exemple, date hachée avec secret, heure hachée avec secret, ou horodatage de manière réversible crypté). Vous pouvez donc utiliser un magasin avec état, qui évoluera probablement jusqu'à au moins des milliers de demandes par seconde sans problème et choisira une option plus performante si nécessaire. –