Authentification basée sur un jeton de l'API REST

Question

Je suis le développement d'une API REST qui nécessite une authentification. Parce que lui-même l'authentification se fait par un externe webservice sur HTTP, j'ai pensé que nous permettrait de se passer de jetons pour éviter à plusieurs reprises d'appeler le service d'authentification. Ce qui m'amène parfaitement à ma première question:

Est-ce vraiment mieux que simplement exiger que les clients utilisent HTTP Basic Auth sur chaque demande de mise en cache et les appels vers le service d'authentification côté serveur?

Le Basic Auth solution a l'avantage de ne pas nécessiter une pleine aller-retour vers le serveur avant que les demandes pour le contenu peut commencer. Les jetons peuvent potentiellement être plus flexible dans le champ d'application (c'est à dire qu'à accorder des droits à des ressources particulières ou des actions), mais qui me semble plus approprié à la OAuth contexte de que mon plus simple de cas d'utilisation.

Actuellement, les jetons sont acquis comme ceci:

curl -X POST localhost/token --data "api_key=81169d80...
                                     &verifier=2f5ae51a...
                                     &timestamp=1234567
                                     &user=foo
                                     &pass=bar"

L' api_key, timestamp et verifier sont requis par toutes les demandes. Le "vérificateur" est renvoyé par:

sha1(timestamp + api_key + shared_secret)

Mon intention est de n'autoriser que les appels provenant de parties, et pour empêcher les appels à partir de la réutilisation des verbatim.

Est-ce bien suffisant? Underkill? Overkill?

Avec un jeton dans la main, les clients peuvent acquérir des ressources:

curl localhost/posts?api_key=81169d80...
                    &verifier=81169d80...
                    &token=9fUyas64...
                    &timestamp=1234567

Pour le plus simple appel possible, ce qui semble sorte de terriblement bavard. Compte tenu de la shared_secret sera le vent se embarqués dans (au moins) une application iOS, dont je suppose qu'il peut être extraite, est-ce même d'offrir quelque chose au-delà d'un faux sentiment de sécurité?

Answer 1

Permettez-moi de séparer tout et résoudre l'approche de chaque problème dans l'isolement:

L'authentification

Pour l'authentification, baseauth a l'avantage que c'est une solution mature sur le protocole de niveau de. Cela signifie beaucoup de "peut survenir plus tard" les problèmes sont déjà résolus pour vous. Par exemple, avec BaseAuth, les agents utilisateurs connaissent le mot de passe est un mot de passe afin de ne pas mettre en cache.

La charge du serveur d'Auth

Si vous dispenser un jeton de l'utilisateur, au lieu de la mise en cache de l'authentification sur votre serveur, vous êtes encore en train de faire la même chose: la mise en Cache des informations d'authentification. La seule différence est que vous êtes en tournant la responsabilité de la mise en cache de l'utilisateur. Il semble que ce travail inutile pour l'utilisateur, sans gains, donc je vous recommande de gérer cela de manière transparente sur votre serveur comme vous l'avez suggéré.

Sécurité De La Transmission

Si vous pouvez utiliser une connexion SSL, c'est tout ce qu'il y a là, la connexion est sécurisée*. Pour empêcher l'activation accidentelle de l'exécution de plusieurs, vous pourrez filtrer plusieurs url ou de demander aux utilisateurs d'inclure une composante aléatoire ("nonce") dans l'URL.

url = username:key@myhost.com/api/call/nonce

Si cela n'est pas possible, et l'information transmise n'est pas un secret, je vous conseillons de sécuriser la demande avec une table de hachage, comme vous l'avez suggéré dans le jeton d'approche. Depuis le hachage fournit la sécurité, vous pouvez demander à vos utilisateurs de fournir de la valeur de hachage comme le baseauth mot de passe. Pour l'amélioration de la robustesse, je recommande d'utiliser une chaîne de caractères aléatoires au lieu de l'horodatage comme un "nonce" pour prévenir les attaques de relecture (deux légitime demandes peuvent être faites durant la même seconde). Au lieu de fournir distinct "secret partagé" et "api key" champs, vous pouvez simplement utiliser la clé api secret partagé, et ensuite utiliser un sel qui ne change pas, pour éviter arc-en-ciel de la table des attaques. Le champ nom d'utilisateur semble être un bon endroit pour mettre le nonce trop, car il est une partie de l'auth. Alors maintenant, vous avez un propre appeler comme ceci:

nonce = generate_secure_password(length: 16);
one_time_key = nonce + '-' + sha1(nonce+salt+shared_key);
url = username:one_time_key@myhost.com/api/call

Il est vrai que c'est un peu laborieux. C'est parce que vous n'êtes pas en utilisant un protocole de niveau de la solution (comme SSL). Donc, il pourrait être une bonne idée de fournir une sorte de kit de développement pour les utilisateurs de telle sorte qu'au moins ils n'ont pas à passer par eux-mêmes. Si vous avez besoin de le faire de cette façon, je trouve le niveau de sécurité approprié (juste le droit de tuer).

Sécurisé secret de stockage

Cela dépend de qui vous êtes à essayer de le contrecarrer. Si vous êtes à la prévention des personnes ayant accès au téléphone de l'utilisateur à l'aide de votre service de REPOS dans le nom de l'utilisateur, alors il serait une bonne idée de trouver une sorte de porte-clés de l'API sur l'OS cible et avoir le SDK (ou le réalisateur) stockage de la clé. Si ce n'est pas possible, vous pouvez au moins faire un peu plus pour obtenir le secret en les cryptant et en les stockant les données chiffrées et la clé de chiffrement dans divers endroits.

Si vous êtes en essayant de garder les autres vendeurs de logiciels d'obtenir votre clé API pour empêcher le développement d'autres clients, seul le chiffrer-et-magasin-séparément approche presque œuvres. C'est la whitebox crypto, et à ce jour, personne n'est venu avec une véritable solution aux problèmes de cette classe. Le moins que l'on puisse faire est toujours question d'une clé unique pour chaque utilisateur de sorte que vous pouvez interdiction abusé de touches.

(*) EDIT: les connexions SSL ne devrait plus être considéré comme sécurisé , sans prendre d'autres mesures pour vérifier .

Answer 2

Un pur API RESTful doit utiliser le protocole sous-jacent caractéristiques standard:

1. Pour HTTP, l'API RESTful doivent respecter HTTP existants en-têtes standard. L'ajout d'un nouvel en-tête HTTP viole le RESTE principes. Ne pas ré-inventer la roue, utiliser toutes les fonctionnalités standard dans HTTP/1.1 normes, y compris l'état de codes de réponse, en-têtes, et ainsi de suite. Les services web RESTFul devrait mettre à profit et de s'appuyer sur les normes HTTP.

2. Services RESTful DOIT être APATRIDES. Toutes les astuces, tels que le jeton d'authentification basée sur les qui tente de se rappeler l'état de précédentes requêtes REST sur le serveur viole le RESTE principes. Encore une fois, c'est un must, c'est, si vous serveur web enregistre toute demande/réponse en contexte de l'information connexe sur le serveur dans la tentative d'établir une sorte de session sur le serveur, puis votre service web n'est PAS Apatride. Et si elle n'est PAS apatride, il n'est PAS de tout repos.

Bas de ligne: Pour l'authentification/autorisation, vous devez utiliser le protocole HTTP standard en-tête d'autorisation. Qui est, vous devez ajouter le HTTP autorisation / en-tête d'authentification à chaque demande ultérieure, qui doit être authentifié. Le RESTE de l'API doit suivre l'Authentification HTTP normes du Système.Les détails de la façon dont cet en-tête doit être mis en forme sont définies dans la RFC 2616 HTTP 1.1 normes – section 14.8 Autorisation de la RFC 2616, et dans la RFC 2617 l'Authentification HTTP: Basic et Digest Authentification d'Accès.

J'ai développé un service RESTful pour le Cisco Prime de Performance Manager. Recherche Google pour l'API REST du document que j'ai écrit pour que l'application pour plus de détails sur les API RESTFul de conformité ici. Dans cette mise en oeuvre, j'ai choisi d'utiliser le protocole HTTP "de Base" régime d'Autorisation. - découvrez la version 1.5 ou au-dessus de l'API REST du document, et de recherche pour l'autorisation dans le document.