<\/p>\n
authentification<\/h3>\n
L\u2019authentification n\u2019est rien d\u2019autre que la validation d\u2019un utilisateur s\u2019il 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 \u00eates 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\u00e9e avec la famille et vous devez avoir une r\u00e9servation pour cela. Vous faites savoir au directeur et ils confirment que vous avez une r\u00e9servation, vous permettant de vous asseoir dans la section priv\u00e9e restaurant r\u00e9serv\u00e9 aux familles. C\u2019est ce que nous appelions l\u2019authentification. Le directeur du restaurant vous a permis de vous asseoir avec votre famille dans un lieu priv\u00e9 avec une r\u00e9servation valide. Nous pouvons dire que la r\u00e9servation est appel\u00e9e la cl\u00e9 d\u2019authentification.<\/p>\n
<\/p>\n
autorisation<\/h3>\n
Maintenant, vous \u00eates autoris\u00e9 dans la chambre priv\u00e9e et vous pouvez utiliser les services r\u00e9serv\u00e9s aux d\u00eeners priv\u00e9s, etc. Vous \u00eates autoris\u00e9 \u00e0 faire tout cela, mais si vous allez dans la cuisine du restaurant et d\u2019ouvrir leur r\u00e9frig\u00e9rateur, ils peuvent dire que vous n\u2019\u00eates pas autoris\u00e9 dans ce domaine. C\u2019est ce qu\u2019on appelle l\u2019autorisation. Vous \u00eates donc autoris\u00e9 \u00e0 entrer, mais apr\u00e8s \u00eatre entr\u00e9 dans le restaurant, vous n\u2019\u00eates pas autoris\u00e9 \u00e0 aller dans certaines zones et non autoris\u00e9 \u00e0 acc\u00e9der \u00e0 une autre zone. C\u2019est donc ce qu\u2019est l\u2019autorisation.<\/p>\n
Maintenant, quand il s\u2019agit d\u2019un site Web, n\u2019importe qui peut entrer dans une page<\/a> de connexion \u00e0 un site Web public. Comme n\u2019importe qui peut entrer dans un restaurant. Personne ne t\u2019arr\u00eatera. Lorsque vous vous connectez avec votre nom d\u2019utilisateur<\/a> et votre mot de passe de site Web, vous \u00eates authentifi\u00e9 et vous pouvez acc\u00e9der au site Web. De la m\u00eame fa\u00e7on que vous avez acc\u00e9 \u00e0 une table priv\u00e9e r\u00e9serv\u00e9e dans un restaurant \u00e0 l\u2019aide d\u2019une r\u00e9servation. Mais apr\u00e8s l\u2019entr\u00e9e, et apr\u00e8s l\u2019authentification, vous pouvez acc\u00e9der \u00e0 certaines sections, mais vous ne pouvez pas \u00eatre en mesure d\u2019acc\u00e9der \u00e0 d\u2019autres sections qui sont comme les sections admin du site Web. Il s\u2019agit donc d\u2019une diff\u00e9rence tr\u00e8s fondamentale entre l\u2019authentification et l\u2019autorisation.<\/p>\n Revenons \u00e0 notre question. Nous voyons toujours l\u2019autorisation dans une API, pourquoi il en est ainsi? Si vous regardez l\u2019API, elle indique un point final o\u00f9 cette adresse \u00e0 une fonction ou une ressource particuli\u00e8re sur l\u2019application. Nous pouvons dire, par exemple, un module sur le back-end de l\u2019application. Lorsque vous essayez r\u00e9ellement d\u2019acc\u00e9der \u00e0 une ressource particuli\u00e8re seule dans l\u2019application, il est plus appropri\u00e9 de l\u2019appeler comme autorisation pour vous, bien qu\u2019il y aura authentification pour v\u00e9rifier votre identit\u00e9. La premi\u00e8re \u00e9tape est toujours l\u2019authentification.<\/p>\n <\/p>\n Puisque nous avons couvert la diff\u00e9rence entre l\u2019authentification et l\u2019autorisation, nous allons maintenant discuter des diff\u00e9rents types d\u2019authentifications API. Les m\u00e9thodes d\u2019authentification de l\u2019API sont vari\u00e9es en fonction de la technique qu\u2019elles utilisent. Les authentifications sont tr\u00e8s importantes parce qu\u2019elles sont directement li\u00e9es \u00e0 la s\u00e9curit\u00e9 de votre syst\u00e8me. C\u2019est pourquoi la priorit\u00e9 va toujours \u00e0 l\u2019authentification HTTP dans n\u2019importe quel syst\u00e8me.<\/p>\n Nous mets en \u00e9vidence cinq m\u00e9canismes majeurs d\u2019ajout de s\u00e9curit\u00e9 \u00e0 une API \u2014 Base, Cl\u00e9 API, Porteur, OAuth1.0\/OAuth 2.0, et OpenID connect. Nous identifierons ce qu\u2019ils font, comment ils fonctionnent, ainsi que les avantages et les inconv\u00e9nients de chaque approche. Enfin, nous allons d\u00e9montrer le test de charge d\u2019une API qui n\u00e9cessite l\u2019authentification en utilisant LoadView<\/a>.<\/p>\n <\/p>\n L\u2019authentification de base HTTP est rarement utilis\u00e9e par l\u2019industrie informatique de nos jours<\/a>, car il est tr\u00e8s facile d\u2019\u00eatre pirat\u00e9, mais c\u2019est la m\u00e9thode la plus simple \u00e0 mettre en \u0153uvre. Les API enverront un nom d\u2019utilisateur et un mot de passe le long du corps. Les informations d\u2019identification seront cod\u00e9es avec la m\u00e9thode de cryptage telle que Base64<\/em>; cela convertira le nom d\u2019utilisateur et le mot de passe en format crypt\u00e9 pour la transmission.<\/p>\n Puisqu\u2019il utilise l\u2019en-t\u00eate pour la transmission des informations d\u2019identification, aucune autre mesure de s\u00e9curit\u00e9 complexe n\u2019est en place. Pas m\u00eame des iD de session ou des cookies.<\/p>\n <\/p>\n Autorisation: Basic Cg4sOnOlY8KyPQ==<\/em><\/p>\n <\/p>\n L\u2019authentification d\u2019acc\u00e8s Digest est plus complexe et avanc\u00e9e que l\u2019authentification de base. Digest utilise une combinaison du mot de passe de l\u2019utilisateur et d\u2019autres attributs pour cr\u00e9er un hachage MD5. Ceci sera ensuite envoy\u00e9 au serveur pour authentification. Il est plus avanc\u00e9 que d\u2019autres m\u00e9canismes de s\u00e9curit\u00e9 car il envoie les informations d\u2019identification comme hachage. Il a \u00e9t\u00e9 cr\u00e9\u00e9 \u00e0 l\u2019origine dans le cadre de RFC 2069, des am\u00e9liorations de s\u00e9curit\u00e9 ont \u00e9t\u00e9 ajout\u00e9es plus tard dans RFC 2617.<\/p>\n Dans l\u2019authentification digeste, c\u2019est le serveur qui d\u00e9couvre le client qui tente d\u2019acc\u00e9der \u00e0 la ressource. Le serveur<\/a> g\u00e9n\u00e9rera une valeur unique, appel\u00e9e \u00ab nonce \u00bb. Plus tard, cette valeur unique sera utilis\u00e9e par le demandeur de ressources pour g\u00e9n\u00e9rer un hachage MD5, qui sera v\u00e9rifi\u00e9 par serveur.<\/p>\n <\/p>\n Les touches API sont largement utilis\u00e9es par rapport \u00e0 l\u2019authentification de base de nos jours. Vous pouvez le voir dans les applications mobiles, ainsi que les applications Web. Les cl\u00e9s API ont \u00e9t\u00e9 cr\u00e9\u00e9es pour r\u00e9soudre<\/a> les vuln\u00e9rabilit\u00e9s de s\u00e9curit\u00e9 associ\u00e9es au m\u00e9canisme de base de l\u2019API. Dans une cl\u00e9 API, une valeur unique est g\u00e9n\u00e9r\u00e9e du c\u00f4t\u00e9 serveur une fois que vous vous authentifiez avec votre nom d\u2019utilisateur et votre mot de passe. Il sera attribu\u00e9 \u00e0 l\u2019utilisateur. Habituellement, cette valeur unique est g\u00e9n\u00e9r\u00e9e en fonction de l\u2019adresse IP et des diff\u00e9rents attributs de l\u2019utilisateur. La plupart du temps, les d\u00e9veloppeurs envoient la cl\u00e9 API dans l\u2019en-t\u00eate d\u2019autorisation.<\/p>\n <\/p>\n api_key: d670d200234faf5480aa11529b01d732<\/em><\/p>\n Il ya certainement beaucoup d\u2019avantages de l\u2019utilisation d\u2019une cl\u00e9 API, par rapport \u00e0 tous les autres m\u00e9canismes de s\u00e9curit\u00e9. Tout d\u2019abord, les touches API sont simples avec une meilleure s\u00e9curit\u00e9. L\u2019inconv\u00e9nient est que n\u2019importe qui peut ramasser cette cl\u00e9 de s\u00e9curit\u00e9 en utilisant l\u2019un des outils de reniflement de r\u00e9seautage. Cela peut \u00eatre conduit \u00e0 des probl\u00e8mes de s\u00e9curit\u00e9 de l\u2019application enti\u00e8re.<\/p>\n <\/p>\n Porteur signifie \u00abune personne ou une chose qui porte ou d\u00e9tient quelque chose.\u00bb Comme son nom l\u2019indique, il s\u2019agit d\u2019un syst\u00e8me d\u2019authentification HTTP qui implique des jetons de s\u00e9curit\u00e9. Le porteur de jeton de s\u00e9curit\u00e9 aura acc\u00e8s \u00e0 certaines fonctions ou URL. Le jeton porteur sera g\u00e9n\u00e9ralement g\u00e9n\u00e9r\u00e9 par le serveur en r\u00e9ponse \u00e0 une demande de connexion client. Une fois que l\u2019utilisateur a le jeton porteur du serveur, il doit envoyer le jeton avec l\u2019en-t\u00eate d\u2019autorisation lors de la demande.<\/p>\n <\/p>\n autorisation: <\/em><\/p>\n Porteur eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy93cy8yMDA1LzA1L2lkZW50aXR5L2NsYWltcy9uYW1lIjoiNmUyZTU0NjUtNTRjZi00ZTU2LTk2NDEtNDU4Njg0YjVjNWQyIiwiZXhwIjoxNTkzOTY3ODQ0LCJpc3MiOiJodHRwOlxcd3d3LnNvdWxib29rLm1lIiwiYXVkIjoiaHR0cDpcXHd3dy5zb3VsYm9vay5tZSJ9.adcAYn8U5tn68EVGUGPLYBKcGC8Ohgxm7p45tDnpXVc<\/em><\/p>\n Il a \u00e9t\u00e9 cr\u00e9\u00e9 \u00e0 l\u2019origine dans le cadre d\u2019OAuth2.0 dans RFC-6750. Il ya certainement beaucoup d\u2019avantages d\u2019utiliser des jetons porteurs par rapport \u00e0 tous les autres m\u00e9canismes de s\u00e9curit\u00e9. Les jetons porteurs sont meilleurs en termes de s\u00e9curit\u00e9.<\/p>\n <\/p>\n OAuth est un protocole<\/a> d\u2019autorisation plus s\u00e9curis\u00e9. OAuth<\/a> offre une simplicit\u00e9 tout en fournissant un flux d\u2019autorisation pour les applications. OAuth est g\u00e9n\u00e9ralement utilis\u00e9 par les utilisateurs pour se connecter \u00e0 des sites Web tiers en utilisant leurs comptes Google, Microsoft, Facebook, Slack, par exemple, sans exposer leurs informations d\u2019identification.<\/p>\n OAuth 1.0 est soup\u00e7onn\u00e9 de failles de s\u00e9curit\u00e9 et n\u2019est plus pris en charge. OAuth 2.0 est dot\u00e9 de fonctionnalit\u00e9s de s\u00e9curit\u00e9 avanc\u00e9es et est le meilleur pour l\u2019identification et l\u2019authentification personnelles des comptes d\u2019utilisateurs. OAuth 2.0 permet aux utilisateurs de partager leurs attributs sp\u00e9cifiques avec une application, tout en gardant leurs informations d\u2019identification et d\u2019autres informations secr\u00e8tes. OAuth 1.0 \u00e9tait beaucoup plus compliqu\u00e9 et moins s\u00fbr que OAuth 2.0. Le plus grand changement dans OAuth2.0 est qu\u2019il n\u2019est pas n\u00e9cessaire de signer chaque appel avec un hachage keyed.<\/p>\n Fondamentalement, OAuth se composent de deux jetons pour faire la v\u00e9rification; un jeton d\u2019authentification et un jeton de session. Les jetons d\u2019authentification fonctionnent comme les protocoles de s\u00e9curit\u00e9 cl\u00e9s API, l\u2019application s\u2019authentifie pour acc\u00e9der aux donn\u00e9es des utilisateurs. Les jetons de session sont utilis\u00e9s pour maintenir la session utilisateur et r\u00e9cup\u00e9rer un nouveau jeton d\u2019authentification si le jeton de session est expir\u00e9. OAuth 2.0 combine authentification et autorisation pour permettre plus de s\u00e9curit\u00e9 \u00e0 l\u2019application.<\/p>\n Dans OAuth, l\u2019utilisateur acc\u00e9dera \u00e0 l\u2019application avec des informations d\u2019identification. L\u2019application demandera alors un jeton d\u2019authentification. Le demandeur enverra cette demande \u00e0 un serveur d\u2019authentification, ce qui permettra cette authentification si les informations d\u2019identification sont correctes. Ce jeton d\u2019authentification peut \u00eatre v\u00e9rifi\u00e9 \u00e0 tout moment, ind\u00e9pendamment de l\u2019utilisateur. Cela fera d\u2019OAuth un m\u00e9canisme beaucoup plus s\u00fbr que les autres authentifications HTTP. L\u2019un des principaux inconv\u00e9nients d\u2019OAuth est la complexit\u00e9 de la mise en \u0153uvre. Vous devez avoir une bonne connaissance dans le flux OAuth pour l\u2019int\u00e9grer \u00e0 votre application.<\/p>\n <\/p>\n OpenID Connect est une extension du protocole OAuth 2.0. Il v\u00e9rifie l\u2019identit\u00e9 du client en fonction de l\u2019authentification effectu\u00e9e par un serveur d\u2019autorisation. En outre, il peut obtenir des informations de profil d\u2019utilisateur sur le client. OpenID connect r\u00e9sout en fait beaucoup d\u2019inconv\u00e9nients d\u2019OAuth 2.0 et fournit une meilleure solution pour les utilisateurs finaux et les d\u00e9veloppeurs.<\/p>\n <\/p>\n L\u2019authentification de base HTTP est la plus facile \u00e0 impl\u00e9menter dans votre application, mais elle n\u2019est pas non plus s\u00e9curis\u00e9e du tout. Les informations d\u2019identification sont cod\u00e9es, mais sont envoy\u00e9es en texte clair. L\u2019authentification Digest am\u00e9liore l\u2019authentification de base en envoyant des donn\u00e9es en format hachage. Mais le hachage algorithme MD5 n\u2019est pas complexe du tout et peut \u00eatre pirat\u00e9 tr\u00e8s facilement. Les cl\u00e9s API et le porteur sont presque similaires et offrent une meilleure s\u00e9curit\u00e9 que ci-dessus.<\/p>\n Le protocole OAuth garantit qu\u2019aucun pirate ne peut mettre la main sur les informations des clients. M\u00eame l\u2019application ne peut pas obtenir les informations d\u2019identification du profil client et des informations priv\u00e9es. OpenID Connect \u00e9tablit des protocoles permettant aux applications d\u2019acc\u00e9der aux attributs du client \u00e0 l\u2019aide de l\u2019API RESTful<\/a>. OpenID Connect \u00e9tend le flux de jetons d\u2019autorisation OAuth 2.0 en introduisant de nouveaux jetons. Fondamentalement, OpenID Connect est r\u00e9alis\u00e9 comme une extension d\u2019OAuth 2.0.<\/p>\n <\/p>\n Dans cette section, nous allons impl\u00e9menter l\u2019authentification HTTP API \u00e0 l\u2019aide de LoadView. LoadView vous permet d\u2019effectuer ces t\u00e2ches tr\u00e8s facilement et plus efficacement. Load View offre deux options pour les tests de charge d\u2019authentification API :<\/p>\n <\/p>\n Si vous avez acc\u00e8s \u00e0 l\u2019application, nous pouvons obtenir la demande api en utilisant n\u2019importe quel outil r\u00e9seau. C\u2019est la m\u00e9thode la plus simple. Nous allons montrer une d\u00e9monstration rapide pour configurer chacun des m\u00e9canismes d\u2019authentification HTTP ci-dessus en utilisant LoadView<\/p>\n Remarque : Vous pouvez obtenir des d\u00e9tails de demande de serveur API et des donn\u00e9es corporelles de votre \u00e9quipe de d\u00e9veloppement ou les capturer \u00e0 l\u2019aide de n\u2019importe quel outil de reniflement r\u00e9seau.<\/em><\/p>\n <\/p>\n L\u2019\u00e9cran suivant vous demandera de configurer votre API. Ici, nous allons vous montrer comment vous pouvez configurer diff\u00e9rents m\u00e9canismes d\u2019authentification HTTP dans LoadView.<\/p>\n Authentification de base<\/strong><\/p>\n <\/p>\n Touches API<\/strong><\/p>\n <\/p>\n Jeton porteur<\/strong><\/p>\n <\/p>\n OAuth 2.0<\/strong><\/p>\n OAuth 2.0 et Open ID Connect sont plus complexes \u00e0 configurer. Je vais vous montrer la d\u00e9mo pour OAuth 2.0. Il ya un moyen facile de faire OAuth 2.0 authentification que je vais expliquer apr\u00e8s cette section.<\/p>\n <\/p>\n Configurez les d\u00e9tails du serveur d\u2019authentification OAuth.<\/p>\n <\/p>\n Entrez les informations d\u2019identification et cliquez sur connexion. Le serveur d\u2019authentification redirige l\u2019utilisateur vers votre site Web avec un code comme param\u00e8tre URL.<\/p>\n <\/p>\n <\/p>\n Le serveur API demande au serveur d\u2019authentification pour les informations utilisateur.<\/p>\n <\/p>\n Les serveurs API identifient l\u2019utilisateur et r\u00e9pondent par un jeton d\u2019acc\u00e8s. L\u2019utilisateur envoie ensuite le jeton d\u2019acc\u00e8s au serveur API sur chaque demande. Le serveur API valide et donne acc\u00e8s \u00e0 l\u2019application.<\/p>\n <\/p>\n <\/p>\n Si la premi\u00e8re option n\u2019est pas r\u00e9alisable, vous pouvez l\u2019enregistrer \u00e0 l\u2019aide de l\u2019outil d\u2019enregistrement EveryStep Web Recorder.<\/a> Vous pouvez y acc\u00e9der sur le Web et l\u2019utilisation de l\u2019enregistreur est plus facile et efficace. De plus, vous n\u2019avez pas besoin d\u2019apprendre diff\u00e9rents m\u00e9canismes d\u2019authentification. Ici, nous allons d\u00e9montrer comment faire des tests de charge en utilisant LoadView et en utilisant l\u2019enregistreur Web EveryStep. L\u2019application utilise OAuth 2.0 pour l\u2019authentification.<\/p>\n <\/p>\n Connectez-vous \u00e0 LoadView et sous S\u00e9lectionnez un type de test de charge,<\/em> s\u00e9lectionnez Applications Web<\/em>. Ou tout simplement ouvrir l\u2019enregistreur Web EveryStep<\/a>, entrez votre URL, et commencer \u00e0 enregistrer.<\/p>\n <\/p>\n <\/p>\n <\/p>\n Voil\u00e0. Vous avez enregistr\u00e9 l\u2019authentification de l\u2019application, ayant OAuth 2.0. Rejouez le script enregistr\u00e9 et assurez-vous que tout fonctionne comme pr\u00e9vu. N\u2019est-ce pas simple ? Une fois l\u2019enregistrement termin\u00e9, vous pouvez passer aux \u00e9tapes suivantes pour ex\u00e9cuter votre test de charge.<\/p>\n <\/p>\n Corr\u00e9ler les m\u00e9canismes d\u2019authentification HTTP n\u2019est pas une t\u00e2che facile \u00e0 l\u2019aide d\u2019un outil de test de performance. Vous devez avoir une exp\u00e9rience pratique et des connaissances approfondies sur le fonctionnement du flux d\u2019authentification. En outre, il est tr\u00e8s important de faire des tests de charge pour votre fonctionnalit\u00e9 de connexion. Si votre module de connexion n\u2019est pas en mesure de servir la charge utilisateur simultan\u00e9e attendue, ce sera une perte \u00e9norme pour votre entreprise. Votre connexion \u00e0 l\u2019application est un \u00e9l\u00e9ment essentiel de la fonctionnalit\u00e9 de votre application. <\/strong> Si vous recherchez une bonne solution de test de performance de bout en bout pour vos API Web<\/a>, vous aimerez certainement LoadView. Allez-y et essayez-le d\u00e8s aujourd\u2019hui<\/a>!<\/p>\n[\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section]\n","protected":false},"excerpt":{"rendered":" Dans l\u2019\u00e9conomie d\u2019aujourd\u2019hui ax\u00e9e sur l\u2019IT, les API web sont de plus en plus utilis\u00e9es dans le monde entier. Vous avez probablement consomm\u00e9 ou cr\u00e9\u00e9 vous-m\u00eame une API. Les API traitent d\u2019\u00e9normes quantit\u00e9s de donn\u00e9es \u2013 l\u2019une des principales pr\u00e9occupations que l\u2019organisation des services logiciels recherche sp\u00e9cifiquement pour s\u00e9curiser ces donn\u00e9es. L\u2019id\u00e9e est que les […]<\/p>\n","protected":false},"author":5,"featured_media":21124,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"on","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[549,530,511],"tags":[531,521],"class_list":["post-21113","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-experience-utilisateur","category-test-api","category-tests-de-performance","tag-test-api","tag-test-de-charge"],"yoast_head":"\nTypes d\u2019authentifications HTTP<\/h2>\n
Authentification de base<\/h3>\n
Exemple d\u2019authentification de base dans un en-t\u00eate de demande :<\/h4>\n
Digest Authentification<\/h3>\n
Touches API<\/h3>\n
Exemple d\u2019une cl\u00e9 API<\/h4>\n
porteur<\/h3>\n
Exemple d\u2019authentification du porteur<\/h4>\n
OAuth 1.0 et OAuth 2.0<\/h3>\n
OpenID Connect<\/h3>\n
Quel est le meilleur protocole d\u2019authentification \u00e0 utiliser ?<\/h3>\n
Utilisation de LoadView pour tester une API qui n\u00e9cessite une authentification<\/h2>\n
Authentification API : Option 1<\/h3>\n
\u00a0<\/h5>\n
\u00c9tape 1 : S\u00e9lectionnez un type de test de charge<\/strong><\/h4>\n
Connectez-vous \u00e0 LoadView et sous S\u00e9lectionnez un type de test de<\/em>charge, s\u00e9lectionnez HTTP\/S<\/em>.<\/h5>\n
![\"S\u00e9lectionnez](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/Select-a-Load-Testing-Type-1024x459.png\")
<\/p>\n\u00c9tape 2 : Configurez votre API<\/strong><\/h4>\n
![\"Authentification](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/Basic-Authentication-1024x466.png\")
<\/p>\n![\"Touches](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/API-Keys-1024x465.png\")
<\/p>\n![\"Jeton](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/Bearer-Token-1024x461.png\")
<\/p>\n\u00c9tape 1 : Serveur d\u2019authentification OAuth<\/strong><\/h5>\n
![\"Authentification](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/OAuth-Authentication-1024x437.png\")
<\/p>\n\u00c9tape 2 : Informations d\u2019identification<\/strong><\/h5>\n
![\"Informations](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/OAuth-Authentication-Credentials-1024x462.png\")
<\/p>\n\u00c9tape 3 : Informations sur le serveur<\/strong><\/h5>\n
![\"Informations](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/OAuth-Authentication-Server-Information-1024x457.png\")
<\/p>\n\u00c9tape 4 : Jeton d\u2019acc\u00e8s<\/strong><\/h5>\n
![\"Jetons](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/OAuth-Authentication-Access-Token-1024x449.png\")
<\/p>\nAuthentification API : Option Deux<\/h3>\n
\u00c9tape 1 : Enregistrer un nouveau script<\/strong><\/h4>\n
![\"OAuth](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/OAuth-record-new-script-1024x445.jpg\")
<\/p>\n\u00c9tape 2 : Acc\u00e9dez aux fonctionnalit\u00e9s de connexion<\/strong><\/h4>\n
![\"OAuth](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/OAuth-Sign-In-1024x447.png\")
<\/p>\n![\"OAuth](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/OAuth-Sign-In-Step-2-1024x449.png\")
<\/p>\nPens\u00e9es finales : ApIs Web de test de charge qui exigent l\u2019authentification<\/h2>\n