Je suis chargé de concevoir un système qui permettra à nos utilisateurs de se connecter également à leurs comptes et d'interagir avec notre service à l'aide de leurs téléphones mobiles. Je suis préoccupé par la sécurité de l'application.
Fondamentalement, nous permettons aux gens de se connecter via OAuth avec Facebook ou Twitter. L'application mobile (construite avec Appelerator Titanium) devrait le faire aussi. Lors d'une connexion réussie sur le téléphone, j'ai besoin d'informer mon application que quelqu'un connecté avec FB ou Twitter afin que mon application puisse récupérer l'ID utilisateur spécifique de l'application de l'utilisateur.
Ma première pensée était d'écrire une API que le téléphone pouvait appeler les paramètres tels que l'ID utilisateur Facebook ou Twitter. Je voudrais interroger ma base de données et trouver leur ID utilisateur interne et le retourner au téléphone.
Cela fonctionnerait bien, mais c'est complètement insécurisé. Tout le monde pourrait frapper cette même API avec un ID utilisateur Facebook et l'API de retournerait simplement l'ID interne (et toute autre donnée nécessaire par l'application) sans savoir si la demande est autorisée.
Ceci est ma première application mobile, alors je suis un peu incertain de la bonne façon de mettre en œuvre la sécurité sur mon API.
4 Réponses :
La plupart des configurations d'API incluent un type de type de sécréty ou de l'APIKEY unique au développeur. Puisque vous êtes le seul développeur, vous pouvez simplement définir une clé / hachage dans votre application mobile passée également pour un retour de données réussi.
http://lcsd05.cs.tamu.edu/slides/keynote.pdf est une note clé donnée par Google à propos de la conception d'une bonne API de la masse.
Découvrez également ce Question précédente
Merci mais cela n'en aime pas beaucoup, et le problème ne concerne pas la bonne conception de l'API. Mon inquiétude est qu'il n'ya aucun moyen de savoir qui soumet une demande à mon API. Le téléphone frappera l'API avec des paramètres de demande, mais un pirate informatique pourrait tout aussi facilement construire une demande similaire à la main. Comment pourrais-je éviter ça?
Une clé secrète ne fonctionne que lorsque vous ne le distribuez pas. Je ne peux pas mettre une clé secrète sur un périphérique côté client, car tout le monde peut décompiler l'application ou renifler le trafic pour exposer la clé secrète. Ensuite, ce n'est plus un secret.
@ BH88: Toutes les informations que l'application doit être soumise au serveur peut être décompilée, de sorte que l'application puisse faire, peut être copiée
Nous venons de courir dans la même chose. Avez-vous trouvé une solution des problèmes présentés dans ces commentaires
courir dans cela aussi. La clé secrète peut être décompilée. Pourquoi cette réponse a-t-elle été acceptée?
Enfin, pour votre problème, s'il y a de nouveaux progrès, merci de me le faire savoir, merci!
J'ai également fait face à ce problème, authentifiant l'utilisateur est assez simple mais authentification de l'appareil est beaucoup plus difficile. Comme vous l'avez dit, tout le monde peut se connecter à votre API et présenter un utilisateur authentifié via Facebook et accéder à votre API.
Vous pouvez le gérer avec une authentification SSL mutuelle, mais si la touche est compromise sur n'importe quel périphérique mobile, l'API entière est compromise car tous les périphériques utiliseraient la même paire de clés fournie avec l'application lorsqu'il a été installé.
Qu'est-ce que j'ai finalement fait était de forcer l'appareil à s'inscrire à mon API lorsque l'application est d'abord installée. Le périphérique appelle une API sur mon serveur et est émis un secret de clé API qu'il doit ensuite utiliser pour effectuer tous les autres appels d'API. Ce n'est pas sécurisé pour que vous puissiez écrire un script pour vous inscrire et obtenir une clé API, mais cela me permet de surveiller l'utilisation de l'API et de désactiver les périphériques qui se comportent mal.
C'est la meilleure chose que je puisse trouver, un moyen de verrouiller des appareils non autorisés que j'ai identifiés hors bande.
J'ai eu le même problème et je l'ai résolu en créant ma propre API (PHP) en combinaison avec un serveur proxy (NodeJS). Chaque demande de mon client est en train d'envoyer au serveur proxy, le serveur proxy valide la demande et la transmet à mon API. L'API n'autorise que les demandes du serveur proxy son IP.
Premièrement, l'utilisateur authentifie avec le serveur proxy à l'aide de l'en-tête d'autorisation, si le succès de l'utilisateur obtiendra 2 jetons. Un jeton d'accès et un jeton de rafraîchissement. Le jeton d'accès est utilisé pour faire des demandes et vit 5 minutes dans mon cas. Lorsque le jeton d'accès est expiré, l'utilisateur peut rafraîchir le jeton avec le jeton de rafraîchissement qui vit pour toujours.
Créez un module global de votre application qui gère votre logique clé, stockez vos clés dans vos propriétés locales et utilisez-les lorsque l'utilisateur redémarre l'application afin qu'elles ne soient pas obligées à se réaguer à chaque fois.
Si vous utilisez ceci avec HTTPS, les touches ne peuvent pas être reniflées et que vous ne pouvez pas récupérer les touches si vous décompilez l'application, car ils sont stockés sur le périphérique des utilisateurs et non «codé en dur» dans l'application elle-même. Techniquement si l'attaquant a le périphérique de l'utilisateur, il est capable de décompiler l'application et de récupérer les clés. Je sais cela, mais s'il a déjà accès à l'appareil physique, il serait en mesure d'utiliser toute application de toute façon.
Le serveur proxy enregistre également toutes les demandes entrantes et vous avertit par courrier électronique lorsque quelqu'un essaie des astuces (j'ai créé cela moi-même). J'ai utilisé les modules suivants:
Comment avez-vous travaillé avec ça? J'ai exactement un cas similaire d'utilisation