secret client dans OAuth 2.0

95

Pour utiliser l'api de Google Drive, je dois jouer avec l'authentification en utilisant OAuth2.0. Et j'ai quelques questions à ce sujet.

  1. L'identifiant client et le secret client sont utilisés pour identifier ce qu'est 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? Donc, l'utilisateur afficherait un écran demandant d'accorder l'autorisation à une bonne application même si elle est en fait demandée par une mauvaise application? Si oui, que dois-je faire? Ou en fait je ne devrais pas m'inquiéter à ce sujet?

  2. Dans l'application mobile, nous pouvons intégrer une vue Web à notre application. Et il est facile d'extraire le champ du mot de passe dans la vue Web, car l'application qui demande l'autorisation est en fait un "navigateur". Ainsi, OAuth dans une application mobile n'a pas l'avantage que l'application cliente n'a pas accès aux informations d'identification de l'utilisateur du fournisseur de services?

security oauth google-api oauth-2.0 Ours
la source
2
De plus, je suppose que les gens sont généralement soupçonnés lorsque l'application leur demande leur Facebook, Twitter, Dropbox ou d'autres informations d'identification. Je doute que beaucoup de gens ordinaires lisent les spécifications 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.
Igor Čordaš
Vraiment une bonne question devrait certainement avoir plus de points
Shravan
vous pouvez simplement télécharger le ClientId et le secret depuis votre serveur et l'enregistrer dans un trousseau lors de la première connexion réussie, c'est tout
Shravan
@Sharvan Je me trompe peut-être, mais je pense que les porte-clés sont vulnérables sur les téléphones rootés, donc votre secret client pourrait être rendu public.
chichilatte

Réponses:

16

J'ai commencé à écrire un commentaire à votre question, mais j'ai découvert qu'il y avait trop de choses à dire, alors voici mon point de vue sur le sujet dans la réponse.

  1. Oui, il y a une réelle possibilité pour cela et il y a eu quelques exploits basés sur cela. Il est suggéré de ne pas garder l'application secrète dans votre application, il y a même une partie de la spécification selon laquelle les applications distribuées ne devraient pas utiliser ce jeton. Maintenant, vous pourriez demander, mais XYZ en a besoin pour fonctionner. Dans ce cas, ils n'implémentent pas correctement les spécifications et vous devez A ne pas utiliser ce service (peu probable) ou B essayer de sécuriser le jeton en utilisant des méthodes obscurcissantes pour rendre plus difficile la recherche ou l'utilisation de votre serveur comme proxy.

    Par exemple, il y avait des bogues dans la bibliothèque Facebook pour Android où il y avait une fuite de jetons vers Logs, vous pouvez en savoir plus à ce sujet ici http://attack-secure.com/all-your-facebook-access-tokens-are-belong -à-nous et ici https://www.youtube.com/watch?v=twyL7Uxe6sk . Dans l'ensemble, soyez très prudent quant à votre utilisation des bibliothèques tierces (le bon sens en fait, mais si le détournement de jetons est votre grande préoccupation, ajoutez un autre supplément à la prudence).

  2. Je discute du point 2 depuis un certain temps. J'ai même fait des solutions de contournement dans mes applications afin de modifier les pages de consentement (par exemple en changeant le zoom et la conception pour s'adapter à l'application) mais rien ne m'empêchait de lire les valeurs des champs de la vue Web avec nom d'utilisateur et mot de passe. Par conséquent, je suis totalement d'accord avec votre deuxième point et je trouve qu'il s'agit d'un gros "bug" dans les spécifications OAuth. Le fait que "l'application n'accède pas aux identifiants des utilisateurs" dans la spécification est juste un rêve et donne aux utilisateurs un faux sentiment de sécurité… De plus, je suppose que les gens sont généralement soupçonnés lorsque l'application leur demande leur Facebook, Twitter, Dropbox ou d'autres identifiants. Je doute que beaucoup de gens ordinaires lisent les spécifications 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.

Igor Čordaš
la source
3
Votre identifiant client et votre secret client ne seront pas sécurisés simplement parce que vous les publiez dans un tunnel SSL. Oui, ils sont plus à l'abri des attaques de l'homme au milieu. Si un utilisateur envoie un proxy à votre appel HTTP, il peut accepter le mauvais certificat et voir tout ce que vous publiez. En passant, c'est le moyen le plus simple de voler le secret client de quelqu'un sur les appareils mobiles.
EpicThreeDev
5
J'apprécie votre commentaire mais je ne peux en aucun cas le relier à ma réponse ... Pouvez-vous expliquer pourquoi vous avez commenté ma réponse parce que j'ai explicitement déclaré que le secret client ne devrait pas être utilisé dans les applications distribuées et l'autre point était que il existe des solutions de contournement pour obtenir les informations d'identification des utilisateurs dans les applications même si vous utilisez OAuth, de sorte que les utilisateurs doivent avoir confiance dans le fournisseur d'applications et non dans OAuth.
Igor Čordaš
De plus, je ne comprends pas ce que vous entendez par "Si un utilisateur envoie un proxy à votre appel HTTP", oui, les utilisateurs ont accès aux données qu'ils ont envoyées en utilisant HTTP et ils sont libres de passer des appels par proxy comme ils le souhaitent. Comme j'ai compris, vous suggérez cela comme une alternative intéressante au démontage de l'apk pour obtenir le secret, mais là encore, vous ne devriez pas envoyer le secret d'application en premier lieu.
Igor Čordaš
Donc, pour le point 1), la mauvaise application doit avoir accès au même système et récupérer le jeton d'accès / d'actualisation à partir du même appareil?
gauteh
Ce que vous considérez comme «même système» n'est pas clair dans ce contexte. L'application crée une vue Web dans laquelle la page de confirmation est affichée et peut accéder à toutes les données de cette vue (y compris les cookies ou les paramètres d'url hébergeant le jeton d'accès). L'accès entre applications est également possible dans certains cas, par exemple, si une application peut accéder à d'autres journaux d'application, elle pourrait y trouver le jeton comme mentionné avec le bogue fb lib.
Igor Čordaš
16

J'avais la même question que la question 1 ici, et j'ai fait des recherches moi-même récemment, et ma conclusion est qu'il est normal de ne pas garder le «secret du client» secret. Le type de clients qui ne gardent pas la confidentialité du client secret est appelé «client public» dans la spécification OAuth2. La possibilité qu'une personne malveillante puisse obtenir un 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 fait confiance au client, le client ne peut pas obtenir le code d'autorisation du service simplement en affichant l'ID client et le secret client. Au lieu de cela, le client doit obtenir le code d'autorisation directement de l'utilisateur. (Cela se fait généralement par redirection d'URL, dont je parlerai plus tard.) Donc, pour le client malveillant, il ne suffit pas de connaître l'ID / secret client de confiance de l'utilisateur. Il doit en quelque sorte impliquer ou usurper l'utilisateur pour lui donner le code d'autorisation, ce qui devrait être plus difficile que de simplement connaître l'ID / le secret du client.

2. L'URL de redirection est enregistrée avec l'ID / secret client

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 vers le navigateur de l'utilisateur avec le code d'autorisation. Ensuite, le code d'autorisation sera envoyé du navigateur de l'utilisateur à l'URL de redirection, et le client est censé écouter l'URL de redirection pour recevoir le code d'autorisation. (L'URL de redirection peut également être localhost, et j'ai pensé que c'était une manière typique qu'un «client public» reçoive le code d'autorisation.) Puisque cette URL de redirection est enregistrée au service avec l'ID / secret client, le client malveillant ne avoir un moyen de contrôler où le code d'autorisation est donné.

Hideaki
la source
3
C'est prometteur, avez-vous des références pour cela? Ce serait rassurant de savoir.
gauteh
1
J'ai vu dans les documents Drive que dans les applications installées, le secret du client n'est pas vraiment un secret, mais ils n'ont pas expliqué pourquoi il était acceptable de le stocker ici. Votre explication a beaucoup aidé!
Martin Spasov
1

Réponse à la 2ème question: les API Google pour des raisons de sécurité exigent que l'authentification / connexion ne puisse pas être effectuée dans l'application elle-même (comme les vues Web ne sont pas autorisées) et doit être effectuée en dehors de l'application à l'aide du navigateur pour une meilleure sécurité, ce qui est expliqué plus en détail ci-dessous: https: //developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html

vj
la source
au moins c'est "réparé" 3 ans après que je l'avais demandé :)
Ours le