Dans l’économie d’aujourd’hui axée sur l’IT, les API web sont de plus en plus utilisées dans le monde entier. Vous avez probablement consommé ou créé vous-même une API. Les API traitent d’énormes quantités de données – l’une des principales préoccupations que l’organisation des services logiciels recherche spécifiquement pour sécuriser ces données. L’idée est que les données doivent être stables et sécurisées et ne peuvent être consultées que par les utilisateurs prévus. Le temps, la vitesse et les performances comptent également pour les API. Ici, dans cet article, nous allons discuter des différentes méthodes d’authentification et d’autorisation de l’API qui sont largement utilisées par les organisations de l’IT à travers le monde.
Authentification vs autorisation
Si vous avez déjà travaillé sur une API, vous ne verrez toujours que des en-têtes d’autorisation, pas des en-têtes d’authentification. Vous êtes-vous déjà demandé pourquoi ? Utilisez simplement n’importe quel outil de reniflage réseau comme Fiddler / Wireshark, ou utilisez un outil de test d’API et vérifiez l’API de votre application. Que vous voyiez les en-têtes ou le corps d’une API, votre demande d’API trouvera toujours une autorisation. Donc, avant d’expliquer pourquoi les API n’ont que l’autorisation de ne pas l’authentification, expliquons d’abord la différence entre l’authentification et l’autorisation.
authentification
L’authentification n’est rien d’autre que la validation d’un utilisateur s’il est la bonne personne pour utiliser ce service. Expliquons-le plus loin avec un exemple simple. Supposons que vous visitez un restaurant de votre ville avec votre famille. Vous ouvrez la porte du restaurant et vous êtes accueilli par le directeur. Mais vous ne voulez pas vous asseoir dans un restaurant public dans le restaurant, vous voulez vous asseoir dans une chambre privée avec la famille et vous devez avoir une réservation pour cela. Vous faites savoir au directeur et ils confirment que vous avez une réservation, vous permettant de vous asseoir dans la section privée restaurant réservé aux familles. C’est ce que nous appelions l’authentification. Le directeur du restaurant vous a permis de vous asseoir avec votre famille dans un lieu privé avec une réservation valide. Nous pouvons dire que la réservation est appelée la clé d’authentification.
autorisation
Maintenant, vous êtes autorisé dans la chambre privée et vous pouvez utiliser les services réservés aux dîners privés, etc. Vous êtes autorisé à faire tout cela, mais si vous allez dans la cuisine du restaurant et d’ouvrir leur réfrigérateur, ils peuvent dire que vous n’êtes pas autorisé dans ce domaine. C’est ce qu’on appelle l’autorisation. Vous êtes donc autorisé à entrer, mais après être entré dans le restaurant, vous n’êtes pas autorisé à aller dans certaines zones et non autorisé à accéder à une autre zone. C’est donc ce qu’est l’autorisation.
Maintenant, quand il s’agit d’un site Web, n’importe qui peut entrer dans une page de connexion à un site Web public. Comme n’importe qui peut entrer dans un restaurant. Personne ne t’arrêtera. Lorsque vous vous connectez avec votre nom d’utilisateur et votre mot de passe de site Web, vous êtes authentifié et vous pouvez accéder au site Web. De la même façon que vous avez accé à une table privée réservée dans un restaurant à l’aide d’une réservation. Mais après l’entrée, et après l’authentification, vous pouvez accéder à certaines sections, mais vous ne pouvez pas être en mesure d’accéder à d’autres sections qui sont comme les sections admin du site Web. Il s’agit donc d’une différence très fondamentale entre l’authentification et l’autorisation.
Revenons à notre question. Nous voyons toujours l’autorisation dans une API, pourquoi il en est ainsi? Si vous regardez l’API, elle indique un point final où cette adresse à une fonction ou une ressource particulière sur l’application. Nous pouvons dire, par exemple, un module sur le back-end de l’application. Lorsque vous essayez réellement d’accéder à une ressource particulière seule dans l’application, il est plus approprié de l’appeler comme autorisation pour vous, bien qu’il y aura authentification pour vérifier votre identité. La première étape est toujours l’authentification.
Types d’authentifications HTTP
Puisque nous avons couvert la différence entre l’authentification et l’autorisation, nous allons maintenant discuter des différents types d’authentifications API. Les méthodes d’authentification de l’API sont variées en fonction de la technique qu’elles utilisent. Les authentifications sont très importantes parce qu’elles sont directement liées à la sécurité de votre système. C’est pourquoi la priorité va toujours à l’authentification HTTP dans n’importe quel système.
Nous mets en évidence cinq mécanismes majeurs d’ajout de sécurité à une API — Base, Clé API, Porteur, OAuth1.0/OAuth 2.0, et OpenID connect. Nous identifierons ce qu’ils font, comment ils fonctionnent, ainsi que les avantages et les inconvénients de chaque approche. Enfin, nous allons démontrer le test de charge d’une API qui nécessite l’authentification en utilisant LoadView.
Authentification de base
L’authentification de base HTTP est rarement utilisée par l’industrie informatique de nos jours, car il est très facile d’être piraté, mais c’est la méthode la plus simple à mettre en œuvre. Les API enverront un nom d’utilisateur et un mot de passe le long du corps. Les informations d’identification seront codées avec la méthode de cryptage telle que Base64; cela convertira le nom d’utilisateur et le mot de passe en format crypté pour la transmission.
Puisqu’il utilise l’en-tête pour la transmission des informations d’identification, aucune autre mesure de sécurité complexe n’est en place. Pas même des iD de session ou des cookies.
Exemple d’authentification de base dans un en-tête de demande :
Autorisation: Basic Cg4sOnOlY8KyPQ==
Digest Authentification
L’authentification d’accès Digest est plus complexe et avancée que l’authentification de base. Digest utilise une combinaison du mot de passe de l’utilisateur et d’autres attributs pour créer un hachage MD5. Ceci sera ensuite envoyé au serveur pour authentification. Il est plus avancé que d’autres mécanismes de sécurité car il envoie les informations d’identification comme hachage. Il a été créé à l’origine dans le cadre de RFC 2069, des améliorations de sécurité ont été ajoutées plus tard dans RFC 2617.
Dans l’authentification digeste, c’est le serveur qui découvre le client qui tente d’accéder à la ressource. Le serveur générera une valeur unique, appelée « nonce ». Plus tard, cette valeur unique sera utilisée par le demandeur de ressources pour générer un hachage MD5, qui sera vérifié par serveur.
Touches API
Les touches API sont largement utilisées par rapport à l’authentification de base de nos jours. Vous pouvez le voir dans les applications mobiles, ainsi que les applications Web. Les clés API ont été créées pour résoudre les vulnérabilités de sécurité associées au mécanisme de base de l’API. Dans une clé API, une valeur unique est générée du côté serveur une fois que vous vous authentifiez avec votre nom d’utilisateur et votre mot de passe. Il sera attribué à l’utilisateur. Habituellement, cette valeur unique est générée en fonction de l’adresse IP et des différents attributs de l’utilisateur. La plupart du temps, les développeurs envoient la clé API dans l’en-tête d’autorisation.
Exemple d’une clé API
api_key: d670d200234faf5480aa11529b01d732
Il ya certainement beaucoup d’avantages de l’utilisation d’une clé API, par rapport à tous les autres mécanismes de sécurité. Tout d’abord, les touches API sont simples avec une meilleure sécurité. L’inconvénient est que n’importe qui peut ramasser cette clé de sécurité en utilisant l’un des outils de reniflement de réseautage. Cela peut être conduit à des problèmes de sécurité de l’application entière.
porteur
Porteur signifie «une personne ou une chose qui porte ou détient quelque chose.» Comme son nom l’indique, il s’agit d’un système d’authentification HTTP qui implique des jetons de sécurité. Le porteur de jeton de sécurité aura accès à certaines fonctions ou URL. Le jeton porteur sera généralement généré par le serveur en réponse à une demande de connexion client. Une fois que l’utilisateur a le jeton porteur du serveur, il doit envoyer le jeton avec l’en-tête d’autorisation lors de la demande.
Exemple d’authentification du porteur
autorisation:
Porteur eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy93cy8yMDA1LzA1L2lkZW50aXR5L2NsYWltcy9uYW1lIjoiNmUyZTU0NjUtNTRjZi00ZTU2LTk2NDEtNDU4Njg0YjVjNWQyIiwiZXhwIjoxNTkzOTY3ODQ0LCJpc3MiOiJodHRwOlxcd3d3LnNvdWxib29rLm1lIiwiYXVkIjoiaHR0cDpcXHd3dy5zb3VsYm9vay5tZSJ9.adcAYn8U5tn68EVGUGPLYBKcGC8Ohgxm7p45tDnpXVc
Il a été créé à l’origine dans le cadre d’OAuth2.0 dans RFC-6750. Il ya certainement beaucoup d’avantages d’utiliser des jetons porteurs par rapport à tous les autres mécanismes de sécurité. Les jetons porteurs sont meilleurs en termes de sécurité.
OAuth 1.0 et OAuth 2.0
OAuth est un protocole d’autorisation plus sécurisé. OAuth offre une simplicité tout en fournissant un flux d’autorisation pour les applications. OAuth est généralement utilisé par les utilisateurs pour se connecter à des sites Web tiers en utilisant leurs comptes Google, Microsoft, Facebook, Slack, par exemple, sans exposer leurs informations d’identification.
OAuth 1.0 est soupçonné de failles de sécurité et n’est plus pris en charge. OAuth 2.0 est doté de fonctionnalités de sécurité avancées et est le meilleur pour l’identification et l’authentification personnelles des comptes d’utilisateurs. OAuth 2.0 permet aux utilisateurs de partager leurs attributs spécifiques avec une application, tout en gardant leurs informations d’identification et d’autres informations secrètes. OAuth 1.0 était beaucoup plus compliqué et moins sûr que OAuth 2.0. Le plus grand changement dans OAuth2.0 est qu’il n’est pas nécessaire de signer chaque appel avec un hachage keyed.
Fondamentalement, OAuth se composent de deux jetons pour faire la vérification; un jeton d’authentification et un jeton de session. Les jetons d’authentification fonctionnent comme les protocoles de sécurité clés API, l’application s’authentifie pour accéder aux données des utilisateurs. Les jetons de session sont utilisés pour maintenir la session utilisateur et récupérer un nouveau jeton d’authentification si le jeton de session est expiré. OAuth 2.0 combine authentification et autorisation pour permettre plus de sécurité à l’application.
Dans OAuth, l’utilisateur accédera à l’application avec des informations d’identification. L’application demandera alors un jeton d’authentification. Le demandeur enverra cette demande à un serveur d’authentification, ce qui permettra cette authentification si les informations d’identification sont correctes. Ce jeton d’authentification peut être vérifié à tout moment, indépendamment de l’utilisateur. Cela fera d’OAuth un mécanisme beaucoup plus sûr que les autres authentifications HTTP. L’un des principaux inconvénients d’OAuth est la complexité de la mise en œuvre. Vous devez avoir une bonne connaissance dans le flux OAuth pour l’intégrer à votre application.
OpenID Connect
OpenID Connect est une extension du protocole OAuth 2.0. Il vérifie l’identité du client en fonction de l’authentification effectuée par un serveur d’autorisation. En outre, il peut obtenir des informations de profil d’utilisateur sur le client. OpenID connect résout en fait beaucoup d’inconvénients d’OAuth 2.0 et fournit une meilleure solution pour les utilisateurs finaux et les développeurs.
Quel est le meilleur protocole d’authentification à utiliser ?
L’authentification de base HTTP est la plus facile à implémenter dans votre application, mais elle n’est pas non plus sécurisée du tout. Les informations d’identification sont codées, mais sont envoyées en texte clair. L’authentification Digest améliore l’authentification de base en envoyant des données en format hachage. Mais le hachage algorithme MD5 n’est pas complexe du tout et peut être piraté très facilement. Les clés API et le porteur sont presque similaires et offrent une meilleure sécurité que ci-dessus.
Le protocole OAuth garantit qu’aucun pirate ne peut mettre la main sur les informations des clients. Même l’application ne peut pas obtenir les informations d’identification du profil client et des informations privées. OpenID Connect établit des protocoles permettant aux applications d’accéder aux attributs du client à l’aide de l’API RESTful. OpenID Connect étend le flux de jetons d’autorisation OAuth 2.0 en introduisant de nouveaux jetons. Fondamentalement, OpenID Connect est réalisé comme une extension d’OAuth 2.0.
Utilisation de LoadView pour tester une API qui nécessite une authentification
Dans cette section, nous allons implémenter l’authentification HTTP API à l’aide de LoadView. LoadView vous permet d’effectuer ces tâches très facilement et plus efficacement. Load View offre deux options pour les tests de charge d’authentification API :
Authentification API : Option 1
Si vous avez accès à l’application, nous pouvons obtenir la demande api en utilisant n’importe quel outil réseau. C’est la méthode la plus simple. Nous allons montrer une démonstration rapide pour configurer chacun des mécanismes d’authentification HTTP ci-dessus en utilisant LoadView
Remarque : Vous pouvez obtenir des détails de demande de serveur API et des données corporelles de votre équipe de développement ou les capturer à l’aide de n’importe quel outil de reniflement réseau.
Étape 1 : Sélectionnez un type de test de charge
Connectez-vous à LoadView et sous Sélectionnez un type de test decharge, sélectionnez HTTP/S.
Étape 2 : Configurez votre API
L’écran suivant vous demandera de configurer votre API. Ici, nous allons vous montrer comment vous pouvez configurer différents mécanismes d’authentification HTTP dans LoadView.
Authentification de base
Touches API
Jeton porteur
OAuth 2.0
OAuth 2.0 et Open ID Connect sont plus complexes à configurer. Je vais vous montrer la démo pour OAuth 2.0. Il ya un moyen facile de faire OAuth 2.0 authentification que je vais expliquer après cette section.
Étape 1 : Serveur d’authentification OAuth
Configurez les détails du serveur d’authentification OAuth.
Étape 2 : Informations d’identification
Entrez les informations d’identification et cliquez sur connexion. Le serveur d’authentification redirige l’utilisateur vers votre site Web avec un code comme paramètre URL.
Étape 3 : Informations sur le serveur
Le serveur API demande au serveur d’authentification pour les informations utilisateur.
Étape 4 : Jeton d’accès
Les serveurs API identifient l’utilisateur et répondent par un jeton d’accès. L’utilisateur envoie ensuite le jeton d’accès au serveur API sur chaque demande. Le serveur API valide et donne accès à l’application.
Authentification API : Option Deux
Si la première option n’est pas réalisable, vous pouvez l’enregistrer à l’aide de l’outil d’enregistrement EveryStep Web Recorder. Vous pouvez y accéder sur le Web et l’utilisation de l’enregistreur est plus facile et efficace. De plus, vous n’avez pas besoin d’apprendre différents mécanismes d’authentification. Ici, nous allons démontrer comment faire des tests de charge en utilisant LoadView et en utilisant l’enregistreur Web EveryStep. L’application utilise OAuth 2.0 pour l’authentification.
Étape 1 : Enregistrer un nouveau script
Connectez-vous à LoadView et sous Sélectionnez un type de test de charge, sélectionnez Applications Web. Ou tout simplement ouvrir l’enregistreur Web EveryStep, entrez votre URL, et commencer à enregistrer.
Étape 2 : Accédez aux fonctionnalités de connexion
Voilà. Vous avez enregistré l’authentification de l’application, ayant OAuth 2.0. Rejouez le script enregistré et assurez-vous que tout fonctionne comme prévu. N’est-ce pas simple ? Une fois l’enregistrement terminé, vous pouvez passer aux étapes suivantes pour exécuter votre test de charge.
Pensées finales : ApIs Web de test de charge qui exigent l’authentification
Corréler les mécanismes d’authentification HTTP n’est pas une tâche facile à l’aide d’un outil de test de performance. Vous devez avoir une expérience pratique et des connaissances approfondies sur le fonctionnement du flux d’authentification. En outre, il est très important de faire des tests de charge pour votre fonctionnalité de connexion. Si votre module de connexion n’est pas en mesure de servir la charge utilisateur simultanée attendue, ce sera une perte énorme pour votre entreprise. Votre connexion à l’application est un élément essentiel de la fonctionnalité de votre application. Si vous recherchez une bonne solution de test de performance de bout en bout pour vos API Web, vous aimerez certainement LoadView. Allez-y et essayez-le dès aujourd’hui!