Comment conserver les informations d'identification du client confidentiel, tout en utilisant OAuth2 des Ressources du Mot de passe du Propriétaire des informations d'Identification de type de subvention
Nous construisons un service rest et nous voulons utiliser OAauth 2 pour l'autorisation. Le projet actuel (v2-16 du 19 Mai) décrit quatre types de subventions. Ce sont des mécanismes ou des flux de trésorerie pour l'obtention de l'autorisation (un jeton d'accès).
- Code D'Autorisation
- De Reconnaissance Implicite De L'
- Ressources Propriétaire Des Informations D'Identification
- Informations D'Identification Du Client
Il semble que nous devons soutenir tous les quatre d'entre eux, puisqu'ils servent à des fins différentes. Les deux premiers (et probablement la dernière) peut être utilisé à partir d'applications tierces qui ont besoin d'accéder à l'API. Le code d'autorisation est la norme de façon à autoriser une application web qui a la chance de résider sur un serveur sécurisé, tandis que la reconnaissance implicite de l'écoulement serait le choix pour une application client qui n'arrive pas à tenir ses informations d'identification confidentiel (par exemple mobile/application de bureau, JavaScript client, etc.).
Nous voulons utiliser le troisième mécanisme de nous-mêmes pour fournir une meilleure expérience utilisateur sur les appareils mobiles – au lieu de prendre l'utilisateur pour un dialogue de connexion dans un navigateur web, et ainsi de suite, l'utilisateur devra tout simplement saisir son nom d'utilisateur et le mot de passe directement dans l'application et connectez-vous.
Nous voulons également utiliser les informations d'Identification du Client le type de subvention obtenir un jeton d'accès qui peut être utilisé pour afficher des données publiques n'est pas associé à un utilisateur. Dans ce cas, ce n'est pas tant d'autorisation, mais plutôt quelque chose de semblable à une clé API que nous utilisons pour donner accès qu'aux applications qui ont enregistré avec nous, nous donnant une option pour révoquer les droits d'accès en cas de besoin.
Donc mes questions sont:
- Pensez-vous j'ai compris le but de les différents types de subventions correctement?
- Comment pouvez-vous conserver vos informations d'identification du client confidentiel? Dans les troisième et quatrième cas, nous avons besoin de l'id du client et le client secret quelque part sur le client, qui ne sonne pas comme une bonne idée.
- Même si vous utilisez la reconnaissance implicite de type et de ne pas exposer votre client secret, ce qui empêche une autre application d'usurper l'identité de votre application en utilisant le même mécanisme d'autorisation et de votre identifiant client?
Pour résumer, nous voulons être en mesure d'utiliser les informations d'identification du client et des ressources propriétaire des informations d'identification de flux à partir d'une application cliente. Deux de ces flux vous obliger à stocker le client secret, en quelque sorte, mais le client est un mobile ou JavaScript de l'application, de sorte que ceux-ci pourraient facilement être volé.
Vous devez vous connecter pour publier un commentaire.
Je suis confronté à des problèmes similaires, et je suis relativement nouveau à OAuth. J'ai mis en place la "Ressource Propriétaire d'un Mot de passe" dans notre API pour notre application mobile officielle pour utiliser-le web des flux sembler juste comme elles étaient tellement horrible à utiliser sur une plate-forme mobile, et une fois que l'utilisateur installe une application et espère qu'il est de notre application officielle, ils doivent se sentir à l'aise entrant le nom d'utilisateur/mot de passe directement dans l'application.
Le problème est, comme vous le soulignez, il n'existe aucun moyen pour mon API serveur sécurisé pour vérifier le client_id de l'application. Si je comprend un client_secret dans le code de l'application/du package, puis elle est exposée à toute personne qui installe l'application, donc nécessitant un client_secret ne serait pas rendre le processus plus en sécurité. Donc, fondamentalement, n'importe quelle autre application peut usurper l'identité de mon application en copiant le client_id.
Juste pour obtenir des réponses directes à chacun de vos points:
Je garde la re-lecture de différents projets de spec pour voir si quelque chose a changé, et je suis concentré sur le Propriétaire de la Ressource Mot de passe des informations d'Identification de l'article, mais je pense que vous avez raison sur ces. Informations d'Identification du Client(4) je pense pourrait aussi être utilisé par un interne ou un service tiers qui peut avoir besoin d'accéder à plus que juste des informations "publiques", comme peut-être vous avez analytics ou quelque chose qui a besoin d'obtenir des informations sur tous les utilisateurs.
Je ne pense pas que vous pouvez tenir quelque chose de confidentiel sur le client.
Rien n'empêche quelqu'un d'autre d'utiliser votre numéro de client. C'est mon problème aussi. Une fois votre code quitte le serveur, et est installé comme une application ou l'exécution de Javascript dans un navigateur, vous ne pouvez pas assumer tout est secret.
Pour notre site, nous avons eu un problème similaire à ce que vous décrivez avec le Client les informations d'Identification de flux. Ce que j'ai fini par faire, c'est déplacer l'authentification côté serveur. L'utilisateur peut s'authentifier à l'aide de notre application web, mais le jeton OAuth à notre API sont stockées sur le côté serveur, et associé à l'utilisateur de la session web. Toutes les requêtes à l'API que le code Javascript fait sont en fait des appels AJAX vers le serveur web. Ainsi, le navigateur n'est pas directement authentifié avec l'API, mais au contraire une web authentifiés session.
Il semble être votre cas d'utilisation pour les informations d'Identification du Client est différent, en ce que vous êtes parle d'applications tierces, et ne servant des données publiques par le biais de cette méthode. Je pense que vos préoccupations sont valides (n'importe qui peut voler et utiliser de quelqu'un d'autre clé API), mais si vous avez uniquement besoin d'une inscription gratuite à obtenir une clé API, je ne vois pas pourquoi quelqu'un devrait vraiment envie d'en voler un.
Vous pourriez surveiller et analyser l'utilisation de chaque clé API pour essayer de détecter des abus, à quel point vous pourrait invalider une clé API et de donner à l'utilisateur légitime d'une nouvelle. Ce pourrait être la meilleure option, mais elle n'est absolument pas sécurisé.
Vous pouvez également utiliser un Jeton d'Actualisation-comme le régime de cela si vous voulait l'enfermer un peu plus serré, mais je ne sais pas combien vous vraiment gagner. Si vous expiré le Javascript exposés api jetons une fois par jour et nécessaire de la troisième partie pour faire une sorte de serveur-côté d'actualisation à l'aide d'un (secret) l'actualisation de jeton, puis vol de jetons api ne sera jamais bon pour plus d'un jour. Pourrait encourager le potentiel de jeton de voleurs il suffit de s'inscrire à la place. Mais, un peu de douleur pour tout le monde, donc ne sais pas si cela en vaut la peine.