Système d'authentification API simple et sécurisé

Question

J'ai une simple API REST JSON pour que d'autres sites/applications puissent accéder à certaines bases de données de mon site (via une passerelle PHP). Fondamentalement, le service fonctionne comme ceci: appelez example.com/fruit/orange, le serveur renvoie des informations JSON sur l'orange. Voici le problème: je veux seulement que les sites Web que je permets d'accéder à ce service. Avec un système de clé API simple, n'importe quel site Web peut rapidement atteindre une clé en copiant la clé à partir du code côté client (potentiellement) d'un site autorisé. J'ai regardé OAuth, mais cela semble un peu compliqué pour ce que je fais. Solutions?

Answer 1

Si le code du client d'un autre utilisateur est compromis, il doit obtenir une nouvelle clé. Il n'y a pas grand chose à faire si leur code est exposé.

Vous pouvez toutefois être plus strict en exigeant que les adresses IP des serveurs autorisés soient enregistrées dans votre système pour la clé donnée. Cela ajoute une étape supplémentaire et peut être exagéré. Je ne suis pas sûr de ce que vous voulez dire en utilisant une "clé API simple", mais vous devriez utiliser une sorte d'authentification qui a des clés privées (connues seulement pour le client et le serveur), puis effectuer une sorte d'algorithme de somme de contrôle sur les données pour s'assurer que le client est bien ce que vous pensez qu'il est, et que les données n'ont pas été modifiées en transit. Amazon AWS est un excellent exemple de comment faire cela.

Je pense qu'il peut être un peu strict de garantir que le code n'a pas été compromis du côté de vos clients. Je pense qu'il est raisonnable de placer la responsabilité sur vos clients pour la sécurité de leurs propres données. Bien sûr, cela suppose qu'un attaquant ne peut que gâcher le compte de ce client. Peut-être que vous pourriez garder un journal de ce que les demandes ip viennent d'un compte particulier, et si une nouvelle ip arrive, marquer le compte, envoyer un email au client, et leur demander d'autoriser cette adresse IP. Je ne sais pas peut-être que quelque chose comme ça pourrait marcher.

Answer 2

Fondamentalement, vous avez deux options, soit restreindre l'accès par IP ou alors avoir une clé API, les deux options ont leurs côtés positifs et négatifs.

Restriction par IP
Cela peut être un moyen pratique de restreindre l'accès à votre service. Vous pouvez définir exactement quels services tiers seront autorisés à accéder à votre service sans les forcer à implémenter des fonctions d'authentification spéciales. Le problème avec cette méthode est cependant que si le service tiers est écrit par exemple entièrement en JavaScript, alors l'adresse IP de la requête entrante ne sera pas l'IP du serveur du service tiers, mais l'IP de l'utilisateur, comme la demande est faite par le navigateur de l'utilisateur et non par le serveur. L'utilisation de la restriction IP rend donc impossible l'écriture d'applications pilotées par le client et oblige toutes les requêtes à passer par le serveur avec les droits d'accès appropriés. N'oubliez pas que les adresses IP peuvent également être usurpées. L'avantage avec les clés API est que vous n'avez pas besoin de maintenir une liste d'adresses IP connues, vous devez maintenir une liste de clés API, mais il est plus facile d'automatiser leur maintenance. Fondamentalement, comment cela fonctionne est que vous avez deux clés, par exemple un identifiant d'utilisateur et un mot de passe secret. Chaque demande de méthode à votre service doit fournir un hachage d'authentification composé des paramètres de la requête, de l'ID de l'utilisateur et d'un hachage de ces valeurs (où le mot de passe secret est utilisé comme sel de hachage). De cette façon, vous pouvez à la fois authentifier et restreindre l'accès. Le problème avec ceci est que, encore une fois, si le service tiers est écrit comme piloté par le client (par exemple JavaScript ou ActionScript), alors n'importe qui peut analyser l'id de l'utilisateur et les valeurs de sel secrètes du code. Fondamentalement, si vous voulez être sûr que seuls les quelques services que vous avez spécifiquement définis seront autorisés à accéder à votre service, alors vous seule option est d'utiliser la restriction IP et donc les obliger à acheminer toutes les demandes via leurs serveurs .Si vous utilisez une clé API, vous n'avez aucun moyen de l'appliquer.

Answer 3

Vous devez utiliser OAuth.

Il existe actuellement deux spécifications OAuth, la version à 3 pattes et la version à 2 pattes. La version à 3 pattes est celle qui attire le plus l'attention, et c'est et non celle que vous voulez utiliser. La bonne nouvelle est que la version à 2 pattes fait exactement ce que vous voulez, elle permet à une application d'accorder l'accès à une autre via soit une clé secrète partagée (très similaire au modèle de service Web d'Amazon, vous utiliserez le HMAC- Méthode de signature SHA1) ou via un système de clé publique/privée (utiliser la méthode de signature: RSA-SHA1). Les mauvaises nouvelles, c'est que ce n'est pas encore aussi bien supporté que la version à 3 pattes, donc vous devrez peut-être faire un peu plus de travail que ce que vous auriez pu faire maintenant. Fondamentalement, OAuth à 2 pattes spécifie simplement un moyen de «signer» (calculer un hachage sur) plusieurs champs qui incluent la date actuelle, un nombre aléatoire appelé «nonce», et les paramètres de votre demande. Cela rend très difficile d'emprunter l'identité des demandes à votre service Web. OAuth devient lentement mais sûrement un standard accepté pour ce genre de choses - vous serez mieux à long terme si vous l'adoptez parce que les gens peuvent alors tirer parti des différentes bibliothèques disponibles pour cela. Il est plus élaboré que vous ne le souhaiteriez dans un premier temps, mais la bonne nouvelle est que beaucoup de gens y ont passé beaucoup de temps et que vous savez que vous n'avez rien oublié. Un bon exemple est que très récemment Twitter a trouvé une lacune dans la sécurité OAuth que la communauté travaille actuellement à la fermeture. Si vous aviez inventé votre propre système, vous deviez vous débrouiller seul.

Bonne chance!

Chris

Answer 4

OAuth est pas la solution ici.
OAuth est lorsque vous avez des utilisateurs finaux et que vous souhaitez que les applications tierces ne traitent pas les mots de passe des utilisateurs finaux. Quand utiliser OAuth: http://blog.apigee.com/detail/when_to_use_oauth/

Go pour api simple-clé.
Et prendre des mesures supplémentaires si vous avez besoin d'une solution plus sécurisée.

Voici quelques informations supplémentaires, http://blog.apigee.com/detail/do_you_need_api_keys_api_identity_vs._authorization/

Answer 5

toute la production de la sécurité IP semble produit un bug géant aux utilisateurs avant de se connecter. Symbian 60s a la capacité maximale de laisser un signal non traçant, fiable et sécurisé au milieu de plusieurs utilisateurs (application Opera Handler UI 6.5, Opera Mini v8 et 10) avec les interfaces utilisateur codées, + configuration du réseau complètement rempli. Pourquoi restreindre pour d'autres caractéristiques quand la méthode découvrable de faire la méthode plus rapide de lien est finalement obtenue. Garder des comptes plus identifiés, un suivi correct de ce «vrai compte» - s'ils sont sur la bonne voie - la conformité du paiement des factures et savoir si les utilisateurs ont un solde de maintien non périmé créera un lien plus rapide du signal internet vers le mobile populaire/signaturé industrie. Pourquoi faire des fonctionnalités de sécurité matérielles avant de les envoyer sur le site, une visite mensuelle de leurs comptes peut effacer tous les problèmes de connectivité? Tous les utilisateurs de mobiles ne devraient pas avoir la capacité de se connecter s'ils ont des factures impayées.Pourquoi ne pas fournir un compte d'enregistrement/application 'ALL in One', programmé avec un système d'exploitation, (peut-être un compte e-mail) avec une 'capacité de surveillance' s'ils sont payants ou pas (les problèmes de mot de passe à un autre département). Et si «pas» désactiver leur compte exactement et leurs autres fonctionnalités de lien. Chacun d'entre eux a ses propres intérêts à savoir où se faire accrocher tous les jours, si vous les avez verrouillés/désactivés en raison de factures impayées qui peuvent les initier à se réabonner et les discipliner plus pour devenir des utilisateurs plus responsables et qui peuvent même expirer un compte s'il n'est pas maintenu. La surveillance mensuelle ou l'accès à un «vrai compte» identifié avec collaboration au fournisseur de réseau produit une plus grande confidentialité au lieu de toujours demander aux utilisateurs «nom» et «mot de passe», «emplacement», «autorisations» pour voir leurs services de données. Les IP ont déjà marqué leur première identité ou «trouver l'emplacement des utilisateurs», il semble donc peu judicieux de le placer sur les pré-recherches des navigateurs, pourquoi ne pas utiliser «Obtenir des données» ou «Traiter des données».