Comment puis-je concevoir une sécurité API/Authentification pour les applications mobiles afin d'accéder à un service?
Je veux offrir certaines fonctions de mon webapp pour être utilisé dans d'autres applications (je pense principalement sur les smartphones, car ils offrent plus de fonctionnalités par exemple, GPS, Appareil photo,..).
De ce que j'ai rencontré moi-même jusqu'à présent en termes de d'autres Api par exemple, GoogleMaps, est qu'un 3e partie développeur devra s'enregistrer sur mon site, il obtient une clé API (certains aléatoire UUID) et il doit l'utiliser pour s'authentifier ses demandes à l'encontre de mon site web. So far So good...
Est-il un mécanisme pour protéger l'utilisateur d'une application mobile à partir des applications malveillantes? E. g. une 3ème partie développeur peut créer une application de capture et de tous les nom d'utilisateur/mot de passe de l'utilisateur, de sorte qu'il peut faire de mauvaises choses avec le compteutilisateur.
(E. g. Je pourrais construire une application twitter, la capture de tous les noms d'utilisateur/mots de passe, puis supprimez tous leurs tweets, de poster de nouvelles,..)
Est-il possible de faire pour éviter cela? Autant que je sache, vous pouvez utiliser oauth sur le web de manière à ce que mon site web de la boîte de dialogue de connexion apparaît sur un autre site et de leur demander leur nom d'utilisateur/mot de passe, de sorte qu'il n'est pas démontré que la 3ème partie du site.
Est-il possible de mettre en œuvre une authentification sécurisée pour les applications de smartphone? Comment le feriez-vous?
Si je le vois à droite, l'application mobile a encore besoin d'une zone de texte nom d'utilisateur/mot de passe et ces données pourraient aussi être envoyé par l'application de www.someVeryBadServer.com !?
Je ne vois pas une bonne solution. Je veux dire par l'ouverture de votre application de cette manière, vous êtes l'introduction d'un trou de sécurité peu importe. Peut-être que si vous avez été d'une grande application comme facebook ou google et a fourni les composants de l'INTERFACE utilisateur avec la logique de l'utilisateur, vous pouvez le contrôler. Encore semble très douteux.
OriginalL'auteur codie4711 | 2011-03-17
Vous devez vous connecter pour publier un commentaire.
Pour Android et iPhone, vous pouvez utiliser OAuth sans problèmes, et jusqu'à présent, je pense que c'est la meilleure façon de le faire.
Le flux de ces deux smartphone types est le même que dans les applications web, parce que les deux OS de vous donner la possibilité de démarrer le navigateur web à partir de votre application et de rediriger l'utilisateur de web fournisseur, de sorte qu'il peut autoriser votre demande (token), et ensuite le navigateur pouvez retourner votre utilisateur de l'application par l'intermédiaire du bon de rappel URI. Je n'ai pas encore mis en œuvre l'authentification oauth pour les téléphones mobiles, mais j'ai entendu dire par un ami que c'est possible et que le navigateur mobile peut rediriger l'utilisateur vers votre application avec un programme spécial d'URI, comme
scheme://app/parameters
.Voici quelque chose pour avec android: lien
Il y a deux oauth cas d'utilisation: 2 pattes et 3 pattes
2 pattes, c'est quand vous voulez protéger votre API, de sorte qu'il peut être appelée uniquement à partir authentifié demandes des consommateurs. C'est un régime populaire qui existe à partir de l'âge autant que je sache - le consommateur signe chaque demande avec un consommateur, clé partagée, et le fournisseur de votre API), signe la demande aussi à voir si la correspondance de signature. De cette façon, vous pouvez savoir si l'utilisation de l'API est ok pour que les consommateurs.
3 pattes oauth comprend que l'utilisateur final, le consommateur 3ème partie de l'app. Il est très approprié, si vous voulez protéger votre API de nouveau comme dans les 2 pattes, parce que les demandes sont encore signé, mais également de votre API peuvent être protégés par la fin de l'autorisation de l'utilisateur. Le fournisseur d'accès de l'API émet un jeton et le donne à l'application du consommateur (3e partie app). Alors cette application enregistre le jeton localement et redirige l'utilisateur vers le Fournisseur pour obtenir l'autorisation de le jeton. Lorsque l'utilisateur l'autorise, le fournisseur envoie à l'utilisateur de l'application du consommateur et ensuite, le consommateur peut faire authentifié (signé) et autorisé (par l'utilisateur - 3e étape) les demandes de votre API.
Le protocole n'est pas très compliqué une fois que vous voyez comment il fonctionne, et est très flexible - vous pouvez l'étendre à vos besoins mais vous l'aimez. Je le recommande fortement pour la protection des Api, surtout si l'utilisateur l'autorisation est exigée pour l'accès à l'Api.
C'est un très bon site pour lire sur oauth: http://hueniverse.com/oauth/
--- AJOUTER ---
Il y a certaines implications en matière de sécurité concernant partagé de stockage de la clé dans l'application de consommation - application de téléphone mobile dans votre cas.
Si quelqu'un ouvrir votre programme et de désassembler le code et d'en extraire la clé partagée, alors il peut faire application qui va authentifier avec succès à l'API fournisseur. Cependant, ce n'est pas une préoccupation très importante si l'utilisateur l'autorisation est requise (3-pattes), car l'utilisateur sera toujours demandé de donner l'autorisation de cette fausse application - et maintenant, c'est à l'utilisateur de faire le bon choix. Et à côté de ça - la fausse application ne sera pas en mesure de voler les informations d'identification utilisateur, car avec oauth, des informations d'identification utilisateur inscrit uniquement sur le site du fournisseur.
Et que j'ai lors de l'utilisation de l'authentification oauth? Je ne peux pas juste gérer tous les accès avec les informations d'identification de l'utilisateur a à mon site ? Disons que mon site est twitter.com et j'ai une méthode postUpdate(Chaîne de statut), l'application est seulement autorisé à appeler cette méthode, si elle est autorisée avant en appelant le login(nom d'utilisateur, mot de passe). Où est l'avantage de l'authentification oauth?
Sur votre première question: il y a à la fois des consommateurs key et consumer secret dans la terminologie du protocole oauth 1.0 a; consommation clé est comme ID, de la consommation, le secret est la clé partagée avec laquelle le consommateur signe Toutes les demandes.
OriginalL'auteur luben
Sur votre deuxième question:
Les avantages de ce protocole sont:
Utilisateur peut être demandé la permission quand sensibles de l'API est l'accès en 3ème partie;
Utilisateur ne sera jamais entrer ses informations d'identification à la 3ème partie de l'app. Chaque 3ème partie application n'est pas fiable et est le potentiel vecteur d'attaque.
Par exemple, si vous êtes gmail - fournisseur de l'API et de vous fournir la méthode de service web
login(user, pass)
à la 3e partie les développeurs d'applications, alors qu'ils peuvent faire écran de connexion dans leur application et de connecter les utilisateurs. Toutefois, dans ce processus de leur 3e partie app reçoit directement les informations d'identification utilisateur avant de les envoyer à gmail. Je n'aurais jamais utiliser cette application. Le problème est que la plupart des gens ne sont pas familiers (surtout non technique) avec les conséquences d'une telle utilisation de l'application et les gens qui font des applications sont encore à exploiter cette vieille et l'insécurité façon de faire les choses. Cependant, comme de plus en plus de personnes s'engagent à mettre en œuvre certaines protocole de sécurité comme l'authentification oauth (ou similaire), les gens vont se familiariser avec ce flux et deviendra de plus en plus suspect à ces intrusive applications 3ème partie.Je dis intrusif, car imaginez un instant le scénario suivant:
Vous pouvez faire une API de paiement dans un pays développé comme la Bulgarie ou en Albanie. C'est une très bonne opportunité pour les entreprises, parce que les Cartes de Crédit ne sont pas une commune de la méthode de paiement à tous à ces endroits.
Et cette API fournisseur est protégé par les exposés de méthode de service web de connexion(user, pass). Après la 3e partie de l'app utiliser cette méthode avec les informations d'identification utilisateur (qu'il a déjà pris), il accède à l'
charge(user, amount)
méthode. Il peut ensuite appeler cette méthode API avec tout ce que les paramètres qu'il veut et de les facturer à l'utilisateur avecone hundred thousand million pessos
😀L'utilisateur ne saura même pas jusqu'à ce que plus tard. Et d'ailleurs, on ne peut séparer de l'API de l'appel de méthode par les autorisations - ce que l'utilisateur est accepté et ce qui pas.
Autre inconvénient est que les utilisateurs utilisent un mot de passe pour de nombreux endroits de cette façon, 3e partie application peut accéder à un autre service que l'utilisateur peut utiliser le même mot de passe.
Il est possible qu'ils ne - s'ils ont des informations d'authentification des utilisateurs, ils peuvent aller chercher dans le fond de twitter page de connexion et envoyer des informations d'identification, et tout ce qu'ils ont à faire, après c'est parse la page autorisations et en envoyer une autre demande de soumettre OUI à la place de l'utilisateur. Mais ce n'est pas la façon dont OAuth est censé fonctionner, car de cette façon, la sécurité est le même que d'exposer de connexion(user,pass) méthode directement comme nous avons parlé ci-dessus.
Ok,je l'obtiens.J'ai testé la DroidIn app pour android et c'est en fait l'utilisation de la "oauth" de connexion(si vous n'avez pas de téléphone, vous pouvez le voir ici: droidin.net/wp-content/files/2011/03/login.png. Un clic sur le bouton ouvrir un navigateur où vous pouvez vous connecter à vous-même).Je suis tout à fait de doute maintenant. Mon cerveau est au point que ce mécanisme de connexion est beaucoup plus sûr, mais mon cœur pense que c'est une mauvaise expérience utilisateur: Ouvrez l'app, navigateur (un autre processus) s'ouvre avec la page de connexion, de connexion de là, de retourner à l'application..assez déroutant si vous aussi vous voir non-technophile utilisateurs comme vos clients.
Oui, je suis totalement d'accord qu'il semble porter à confusion. Une chose est que vous pouvez vous souvenir de la décision de l'utilisateur et de cette connexion et d'octroi d'autorisation peut être fait en une seule fois, lorsque l'utilisateur commence à utiliser l'application. Toutefois, le processus semble toujours compliqué, surtout lorsque tout le monde sont utilisés pour entrer directement dans leurs informations d'identification utilisateur.
OriginalL'auteur luben