secret client dans OAuth 2.0
Pour utiliser Google Drive Api, je dois jouer avec l'authentification en utilisant OAuth2.0. Et j'ai quelques questions à ce sujet.
L'ID client et le secret client sont utilisés pour identifier mon application. Mais ils doivent être codés en dur s'il s'agit d'une application cliente. Ainsi, tout le monde peut décompiler mon application et les extraire du code source. Cela signifie-t-il qu'une mauvaise application peut prétendre être une bonne application en utilisant l'identifiant client et le secret de la bonne application? Ainsi, l'utilisateur afficherait un écran demandant l'autorisation d'accorder une bonne application même si une mauvaise application le lui demande? Si oui, que dois-je faire? Ou en fait je ne devrais pas m'inquiéter à ce sujet?
Dans une application mobile, nous pouvons intégrer une vue Web à notre application. Et il est facile d'extraire le champ de mot de passe dans la vue Web, car l'application qui demande l'autorisation est en réalité un "navigateur". Ainsi, OAuth dans l'application mobile n'a pas l'avantage que l'application cliente n'a pas accès aux informations d'identification d'utilisateur du fournisseur de service?
J'ai commencé à écrire un commentaire sur votre question, mais j'ai alors découvert qu'il y avait trop à dire, alors voici mon point de vue sur le sujet dans la réponse.
Oui, il y a une possibilité réelle pour cela et il y a eu quelques exploits basés sur cela. Nous vous suggérons de ne pas garder le secret des applications dans votre application. Certaines applications prévoient même que les applications distribuées ne doivent pas utiliser ce jeton. Maintenant, vous pouvez demander, mais XYZ en a besoin pour fonctionner. Dans ce cas, ils n'implémentent pas correctement les spécifications et vous ne devez pas utiliser ce service (ce qui est peu probable) ou B essayer de sécuriser le jeton à l'aide de méthodes d'obscurcissement afin de rendre plus difficile la recherche ou l'utilisation de votre serveur en tant que proxy.
Par exemple, il y avait des bogues dans la bibliothèque Facebook pour Android où il y avait une fuite de jetons vers les journaux, vous pouvez en savoir plus ici http://attack-secure.com/all-your-facebook-access- jetons-sont-appartiennent-à-nous et ici https://www.youtube.com/watch?v=twyL7Uxe6sk . Dans l’ensemble, faites très attention à votre utilisation de tiers bibliothèques de parti (bon sens en fait, mais si le détournement de jetons est votre préoccupation majeure, ajoutez un autre extra à prudent).
Je discute du point 2 depuis un certain temps. J'ai même effectué quelques solutions de contournement dans mes applications afin de modifier les pages de consentement (par exemple, en modifiant le zoom et le design en fonction de l'application), mais rien ne m'empêchait de lire les valeurs des champs de la vue Web avec un nom d'utilisateur et un mot de passe. Par conséquent, je suis tout à fait d’accord avec votre deuxième point et trouve que c’est un gros "bogue" dans les spécifications OAuth. Le fait de dire que "l'application n'a pas accès aux informations d'identification des utilisateurs" dans la spécification n'est qu'un rêve et donne aux utilisateurs un faux sentiment de sécurité… De plus, je suppose que les gens sont généralement suspects lorsque l'application leur demande leurs identifiants pour Facebook, Twitter, Dropbox ou autres. Je doute que beaucoup de gens ordinaires lisent la spécification OAuth et disent «Maintenant, je suis en sécurité», mais utilisent plutôt le bon sens et n'utilisent généralement pas d'applications auxquelles ils ne font pas confiance.
J'avais la même question que la question 1 ici et j'ai récemment effectué des recherches moi-même, et ma conclusion est qu'il est correct de ne pas garder le secret sur le client "secret". Le type de clients qui ne gardent pas la confidentialité des clients secret est appelé "client public" dans la spécification OAuth2 . La possibilité qu'une personne malveillante puisse obtenir le code d'autorisation, puis un jeton d'accès, est empêchée par les faits suivants.
1. Le client doit obtenir le code d'autorisation directement de l'utilisateur, pas du service.
Même si l'utilisateur indique au service qu'il/elle fait confiance au client, le client ne peut pas obtenir le code d'autorisation du service simplement en indiquant son ID client et son secret client . Le client doit au contraire obtenir le code d'autorisation directement de l'utilisateur. (Cela se fait généralement par la redirection d'URL, ce dont je parlerai plus tard.) Donc, pour le client malveillant, il ne suffit pas de connaître l'identifiant/le secret du client approuvé par l'utilisateur. Il doit en quelque sorte impliquer ou usurper l'utilisateur de lui donner le code d'autorisation, , Ce qui devrait être plus difficile que de simplement connaître l'ID/secret du client.
2. L'URL de redirection est enregistrée avec l'identifiant client/secret
Supposons que le client malveillant ait réussi à impliquer l'utilisateur et à lui faire cliquer sur le bouton "Autoriser cette application" sur la page de service . Cela déclenchera la réponse de redirection d'URL du service au navigateur de l'utilisateur avec le code d'autorisation avec it . Ensuite, le code d'autorisation sera envoyé du navigateur de l'utilisateur à l'URL de redirection, et le client est censé écouter sur l'URL de redirection pour recevoir le code d'autorisation . et j’ai pensé qu’il s’agissait d’un moyen typique pour un “client public” de recevoir un code d’autorisation.) Comme cette URL de redirection est enregistrée sur le service avec le client id/secret, le client malveillant n’a pas le moyen de contrôler le code d'autorisation est donné à . Cela signifie que le client malveillant avec votre identifiant/secret client a un autre obstacle pour obtenir le code d'autorisation de l'utilisateur.
Réponse à la deuxième question: les API Google, pour des raisons de sécurité, indiquent que l’authentification/la connexion ne peut pas être effectuée dans l’application elle-même (les vues Web ne sont pas autorisées) et doit être effectuée en dehors de l’application en utilisant le navigateur pour une sécurité accrue. . https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html