Considérez une API à laquelle un client accède directement (machine à machine) et qui ne nécessite pas d'authentification spécifique à l'utilisateur. D'après ce que je comprends, dans client_credentials , le client doit stocker un client_id et un client_secret qu'il utilise pour acquérir et actualiser les jetons. Avec une clé API, le client stocke simplement la clé. Qu'est-ce qui rend OAuth plus sécurisé dans ce cas? Il me semble que si la clé API n'est jamais compromise, aucun attaquant ne pourrait se faire passer pour le client visé. Et si la clé API est compromise, cela revient en fait à compromettre client_id et client_secret , qu'un attaquant pourrait utiliser pour obtenir des jetons et accéder aux données de l'API, se faisant passer pour le client.
edit: clarifié ceci est un appel de machine à machine
3 Réponses :
Quelle est la différence de sécurité entre les clés API et le flux d'informations d'identification client d'OAuth?
Le flux d'informations d'identification du client OAuth n'est pas destiné à être utilisé par des clients publics, mais uniquement entre des machines.
Sur auth0.com/docs :
Flux d'informations d'identification du client
Avec les applications de machine à machine (M2M), telles que les CLI, les démons ou les services exécutés sur votre back-end, le système authentifie et autorise l'application plutôt qu'un utilisateur. Pour ce scénario, les schémas d'authentification typiques tels que nom d'utilisateur + mot de passe ou connexions sociales n'ont pas de sens. Au lieu de cela, les applications M2M utilisent le flux d'informations d'identification du client (défini dans OAuth 2.0 RFC 6749, section 4.4), dans lequel elles transmettent leur ID client et leur secret client pour s'authentifier et obtenir un jeton.
Donc, je ne sais pas quel est votre scénario, mais je supposerai dans ma réponse que vous faites référence à des clients publics.
D'après ce que je comprends, dans client_credentials, le client doit stocker un client_id et un client_secret qu'il utilise pour acquérir et actualiser les jetons.
Oui, il doit être stocké dans le code client pour que le client puisse obtenir le jeton OAuth.
Si vous utilisez le client_secret depuis une application Web ou une application mobile, vous le client_secret public, donc ce n'est plus un secret.
Par exemple, dans une application Web, tout ce qu'il faut pour extraire le client_secret est d' client_secret sur F12 dans le navigateur et de le rechercher, donc combien de temps cela peut-il prendre?
Maintenant, dans une application mobile, certains peuvent penser que c'est sécurisé car ils sont compilés dans un binaire mais c'est presque aussi simple que dans le navigateur, car nous avons plusieurs outils open-source qui peuvent nous aider dans cette tâche, comme le MobSF framework, et sous Linux, vous pouvez même y parvenir avec la commande strings . L'utilisation de MobSF pour effectuer une analyse binaire statique sur le binaire de l'application mobile permet à quiconque sans connaissances de piratage d'extraire facilement le client_secret en quelques minutes, comme je le montre dans mon article Comment extraire une clé API d'une application mobile avec une analyse binaire statique :
La gamme d'outils open source disponibles pour la rétro-ingénierie est énorme, et nous ne pouvons vraiment pas gratter la surface de ce sujet dans cet article, mais à la place, nous nous concentrerons sur l'utilisation du Mobile Security Framework (MobSF) pour montrer comment faire de l'ingénierie inverse. l'APK de notre application mobile. MobSF est un ensemble d'outils open source qui présentent leurs résultats dans un tableau de bord attrayant, mais les mêmes outils utilisés sous le capot au sein de MobSF et ailleurs peuvent être utilisés individuellement pour obtenir les mêmes résultats.
Ainsi, le processus d'extraction de la api-key dans mon article est le même que vous utiliserez pour extraire le client_secret ou toute autre chaîne de votre intérêt dans le binaire de l'application mobile.
Qu'est-ce qui rend OAuth plus sécurisé dans ce cas? Il me semble que si la clé API n'est jamais compromise, aucun attaquant ne pourrait se faire passer pour le client visé. Et si la clé API est compromise, cela revient en fait à compromettre client_id et client_secret, qu'un attaquant pourrait utiliser pour obtenir des jetons et accéder aux données de l'API, se faisant passer pour le client.
Si elles sont utilisées à partir d'un client public, elles ne sont pas non plus sécurisées, car si vous lisez mon article lié, vous comprenez maintenant à quel point il est facile de contourner une clé API ou d'extraire le client_secret et le client_id .
Ainsi, si votre client est public, vous ne devez pas utiliser le flux d'informations d'identification du client OAuth, vous devez donc utiliser l'approche de clé API non sécurisée ou vous pouvez être plus diligent et essayer d'appliquer des approches de défense en profondeur, mais cela dépendra si les clients API ne sont que des applications Web ou des applications mobiles ou les deux.
Si vos clients API ne sont que des applications Web, je vous invite à lire ma réponse à la question Sécuriser les données API des appels hors de l'application , en particulier la section dédiée à la défense du serveur API.
Dans le cas où les clients API ne sont que des applications mobiles, je vous recommande de lire cette réponse que j'ai donnée à la question Comment sécuriser une API REST pour une application mobile? , en particulier les sections Sécurisation du serveur API et Une meilleure solution possible .
D'un autre côté, si vos clients API sont à la fois une application Web et une application mobile, je vous recommande d'appliquer les mesures de sécurité les plus pertinentes pour vous à partir des deux réponses liées ci-dessus.
N'oubliez pas que la sécurité consiste toujours à ajouter autant de niveaux de défense que vous pouvez vous le permettre ou que la loi l'exige. Même au siècle dernier, les châteaux ont été construits avec de nombreuses couches de défense de sécurité différentes, ce n'est donc rien de nouveau à l'ère numérique.
Dans toute réponse à une question de sécurité, j'aime toujours faire référence à l'excellent travail de la fondation OWASP.
Top 10 de la sécurité de l'API OWASP
Le projet de sécurité des API OWASP cherche à fournir de la valeur aux développeurs de logiciels et aux évaluateurs de sécurité en soulignant les risques potentiels liés aux API non sécurisées et en illustrant comment ces risques peuvent être atténués. Afin de faciliter cet objectif, le projet de sécurité des API OWASP créera et maintiendra un document sur les 10 principaux risques de sécurité des API, ainsi qu'un portail de documentation sur les meilleures pratiques lors de la création ou de l'évaluation des API.
Projet de sécurité mobile OWASP - Top 10 des risques
Le projet OWASP Mobile Security est une ressource centralisée destinée à donner aux développeurs et aux équipes de sécurité les ressources dont ils ont besoin pour créer et maintenir des applications mobiles sécurisées. À travers le projet, notre objectif est de classer les risques de sécurité mobile et de fournir des contrôles de développement pour réduire leur impact ou leur probabilité d'exploitation.
OWASP - Guide de test de sécurité mobile :
Le guide de test de sécurité mobile (MSTG) est un manuel complet pour le développement, les tests et la rétro-ingénierie de la sécurité des applications mobiles.
Le guide des tests de sécurité Web :
Le Guide de test de sécurité Web OWASP comprend un cadre de test de pénétration des «meilleures pratiques» que les utilisateurs peuvent mettre en œuvre dans leur propre organisation et un guide de test de pénétration de «bas niveau» qui décrit les techniques de test des problèmes les plus courants de sécurité des applications Web et des services Web.
Merci pour la réponse détaillée. J'aurais dû être plus clair: cela est destiné aux appels de machine à machine, c'est pourquoi je pensais aux informations d'identification du client.
Ensuite, vous devez modifier votre question et mentionner qu'il s'agit d'un flux machine à machine. Merci de clarifier.
Avec le flux d'informations d'identification du client, votre ID client et votre secret client sont envoyés au serveur d'autorisation pour récupérer un jeton d'accès. Pour toutes les demandes ultérieures adressées aux serveurs API / ressources, vous transmettez le jeton d'accès et non les informations d'identification du client elles-mêmes. Le jeton d'accès est généralement un JWT, qui est un ensemble de revendications codées comprenant l'expiration du jeton ( exp ), pas avant ( nbf ), l'émetteur du jeton ( iss ), la partie autorisée ( azp ), les rôles, les autorisations, etc.
Cela présente un certain nombre d'avantages par rapport à une approche simple de clé API. par exemple
La différence se résume à l'accès direct par rapport à l'accès délégué .
OAuth vous permet de créer un accès délégué. Les avantages de l'accès délégué ne changent pas si un utilisateur est impliqué ou non. Les mêmes arguments qui rendent le flux de code d'autorisation OAuth attractif pour l'accès utilisateur à machine s'appliquent au flux d'informations d'identification du client OAuth pour l'accès machine à machine.
Demandez-vous, voulez-vous que le serveur de ressources gère les informations d'identification du client ou non?
Sur les clients confidentiels pour l'accès de machine à machine, le coût de l'accès délégué par rapport à l'accès direct peut très bien l'emporter sur les avantages. C'est pourquoi tant d'API utilisent encore des clés API. Vous devrez décider cela pour votre cas d'utilisation individuel.
Dans le flux d'informations d'identification du client OAuth, le client envoie un jeton d'accès au serveur de ressources, qu'il a obtenu au préalable par le serveur d'autorisation après avoir présenté son ID client et son secret. Le serveur de ressources ne voit jamais le secret client. Avec une clé API, le client envoie la clé à chaque demande.
OAuth ajoute une couche supplémentaire d'indirection avec le serveur d'autorisation, de sorte que les informations d'identification elles-mêmes ne soient jamais transmises au serveur de ressources. Cela permet au serveur d'autorisation de donner au client un accès uniquement pendant une durée limitée ou avec des autorisations limitées, sans jamais avoir besoin de modifier les informations d'identification du client. Il permet également de révoquer les jetons d'accès sans révoquer les informations d'identification elles-mêmes. Pour plusieurs instances d'un client, cela vous permet de révoquer l'accès pour certains mais pas pour tous.
Bien sûr, tout cela se fait au prix d'une implémentation plus complexe, et d'un aller-retour supplémentaire du client au serveur d'autorisation.
Je ne parlerai pas de la transmission (URL, en-tête, corps, etc.) ou du format (chaîne aléatoire, JWT signé, etc.), car ceux-ci peuvent être les mêmes pour les jetons d'accès comme pour les clés API.
Un autre avantage, peut-être pas si évident, d'OAuth est d'avoir une spécification claire sur laquelle les bibliothèques, la documentation et les discussions peuvent être basées. Avec l'accès direct, il n'y a pas de meilleure pratique unique et différentes personnes peuvent comprendre des choses différentes lorsqu'elles se réfèrent à des méthodes d'accès direct telles que les clés API.