OAuth secrets dans les applications mobiles

Question

Lorsque vous utilisez le protocole d'authentification OAuth, vous avez besoin d'une chaîne secrète obtenue à partir du service que vous souhaitez déléguer. Si vous le faites dans une application web, vous pouvez simplement stocker le secret de votre base de données ou sur le système de fichiers, mais quelle est la meilleure façon de le gérer dans une application mobile (ou une application de bureau pour cette question)?

Le stockage de la chaîne de l'application est évidemment pas bon, que quelqu'un puisse la trouver facilement et en abuse.

Une autre approche serait de les stocker sur votre serveur, et l'application le chercher sur chaque course, ne jamais stocker sur le téléphone. C'est presque aussi mauvais, parce que vous devez inclure l'URL dans l'application.

La seule solution viable que je peux venir avec est d'abord d'obtenir le Jeton d'Accès que la normale (de préférence à l'aide d'un affichage web à l'intérieur de l'application), puis route de la communication par le biais de notre serveur, ce qui pourrait ajouter le secret à la demande de données et de communiquer avec le fournisseur. Puis de nouveau, je suis une sécurité noob, donc je voudrais vraiment entendre certains bien informés des peuples des opinions à ce sujet. Il ne semble pas que la plupart des apps vont à ces longueurs pour garantir la sécurité (par exemple, Facebook Connect semble supposer que vous avez mis au secret dans une chaîne de caractères à droite de votre application).

Autre chose: je ne crois pas que le secret est impliquée dans un premier temps demander le Jeton d'Accès, ce qui pourrait être fait sans la participation de notre propre serveur. Suis-je la corriger?

Answer 1

Oui, c'est un problème avec le OAuth conception que nous sommes face à nous-mêmes. Nous avons opté pour proxy tous les appels par le biais de notre propre serveur. OAuth n'était pas entièrement rincée à l'égard des applications de bureau. Il n'y a pas de préfet de la solution à la question que j'ai trouvé sans modifier le protocole OAuth.

Si vous pensez à ce sujet et de poser la question de savoir pourquoi nous avons des secrets, c'est surtout pour la fourniture et la désactivation des applications. Si notre secret est compromis, alors que le fournisseur ne peut vraiment révoquer l'ensemble de l'application. Puisque nous avons à intégrer notre secret dans l'application de bureau, nous sommes sorta vissé.

La solution est d'avoir un autre secret pour chaque application de bureau. OAuth ne pas faire de ce concept facile. Une façon est de demander à l'utilisateur d'aller et de créer un secret sur leur propre et entrez la clé sur leur propre dans votre application de bureau (certains facebook apps a fait quelque chose de similaire pour une longue période de temps, avoir à l'utilisateur d'aller et de créer de facebook pour l'installation de leurs propres quiz et de la merde). Ce n'est pas une grande expérience pour l'utilisateur.

Je suis en train de travailler sur la proposition de délégation au système pour l'authentification OAuth. Le concept est que l'utilisation de notre propre clé secrète de notre fournisseur, nous pourrions émettre nos propres délégués, secrets à nos clients de bureau (un pour chaque application de bureau essentiellement), puis lors de la auth processus de nous envoyer qui touche de plus haut niveau fournisseur qui appelle de nouveau à nous, et re-valide avec nous. De cette façon, nous pouvons révoquer propres secrets nous délivrer à chaque client de bureau. (Emprunt de beaucoup de la façon dont cela fonctionne à partir de SSL). L'ensemble de ce système serait de préfet pour ajouter de la valeur webservices ainsi que passer des appels à un tiers d'un webservice.

Le processus pourrait également être fait sans la délégation de la vérification des rappels si le niveau supérieur fournisseur fournit une API pour générer et révoquer délégué de nouveaux secrets. Facebook est en train de faire quelque chose de similaire en permettant à facebook apps qui permettent aux utilisateurs de créer des sous-applications.

Il y a quelques discussions sur la question en ligne:

http://blog.atebits.com/2009/02/fixing-oauth/ http://groups.google.com/group/twitter-development-talk/browse_thread/thread/629b03475a3d78a1/de1071bf4b820c14#de1071bf4b820c14

Twitter et Yammer apporte une solution d'authentification pin solution: http://apiwiki.twitter.com/Authentication https://www.yammer.com/api_oauth_security_addendum.html

Answer 2

Avec OAUth 2.0, vous pouvez stocker le secret sur le serveur. Utiliser le serveur d'acquérir un jeton d'accès que vous déplacez ensuite l'application et vous pouvez faire des appels à partir de l'application de la ressource directement.

Avec OAuth 1.0 (Twitter), le secret est nécessaire pour faire des appels de l'API. L'utilisation de proxy appels par le biais du serveur est la seule façon d'assurer le secret n'est pas compromise.

Les deux nécessitent un mécanisme que votre composant serveur sait que c'est votre client en l'appelant. Ce qui tend à faire sur l'installation et l'utilisation d'une plate-forme de mécanisme spécifique pour obtenir un id d'application d'un certain type de l'appel à votre serveur.

(Je suis le rédacteur en chef du protocole OAuth 2.0 spec)

Answer 3

Une solution pourrait être de coder en dur le OAuth secret dans le code, mais pas comme une simple chaîne de caractères. Obscurcir d'une certaine façon - il divisé en segments, décalage de caractères par un décalage, rotation; - effectuer tout ou partie de ces choses. Un pirate peut analyser votre code d'octets et de trouver les cordes, mais l'obfuscation de code peut être difficile à comprendre.

Ce n'est pas une solution infaillible, mais un bon marché.

Selon la valeur de l'exploit, certaines génie des craquelins peuvent aller à des longueurs supérieures à trouver votre code secret. Vous avez besoin de peser les facteurs de coût de mentionné précédemment côté serveur solution, d'incitation pour les craquelins à dépenser plus d'efforts sur la recherche de votre code secret, et de la complexité de masquer vous pouvez mettre en œuvre.

Answer 4

Voici quelque chose à penser. Google propose deux méthodes d'OAuth ... pour les applications Web, où vous enregistrez le domaine et générez une clé unique, et pour les applications installées où vous utilisez la clé "anonyme".

Peut-être ai-je caché quelque chose dans la lecture, mais il semble que partager la clé unique de votre webapp avec une application installée est probablement plus sûr que d'utiliser «anonyme» dans la méthode des applications installées officielles.

Answer 5

Avec OAuth 2.0, vous pouvez simplement utiliser le flux côté client pour obtenir un jeton d'accès et utiliser ensuite ce jeton d'accès pour authentifier toutes les demandes supplémentaires. Alors vous n'avez pas besoin de secret du tout.

Une belle description de la façon de mettre en œuvre cela peut être trouvée ici: https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps