<\/p>\n
autentica\u00e7\u00e3o<\/h3>\n
A autentica\u00e7\u00e3o n\u00e3o \u00e9 nada al\u00e9m de validar um usu\u00e1rio se ele \u00e9 a pessoa certa para usar esse servi\u00e7o. Vamos explicar mais adiante com um exemplo simples. Digamos que voc\u00ea est\u00e1 visitando um restaurante em sua cidade com sua fam\u00edlia. Voc\u00ea abre a porta do restaurante e \u00e9 bem-vindo pelo gerente. Mas voc\u00ea n\u00e3o quer sentar em um restaurante p\u00fablico no restaurante, voc\u00ea quer sentar em um quarto privado com a fam\u00edlia e voc\u00ea tem que ter uma reserva para isso. Voc\u00ea avisa o gerente e eles confirmam que voc\u00ea tem uma reserva, permitindo que voc\u00ea se sente na se\u00e7\u00e3o privada do restaurante reservada para as fam\u00edlias. Ent\u00e3o, isso \u00e9 o que chamamos de autentica\u00e7\u00e3o. Voc\u00ea foi autorizado pelo gerente do restaurante a sentar-se com sua fam\u00edlia em um lugar privado com uma reserva v\u00e1lida. Podemos dizer que a reserva \u00e9 chamada de chave de autentica\u00e7\u00e3o.<\/p>\n
<\/p>\n
autoriza\u00e7\u00e3o<\/h3>\n
Agora, voc\u00ea pode entrar no quarto privado e pode usar os servi\u00e7os reservados para restaurantes privados, etc. Voc\u00ea est\u00e1 autorizado a fazer tudo isso, mas se voc\u00ea entrar na cozinha do restaurante e abrir sua geladeira eles podem dizer que voc\u00ea n\u00e3o \u00e9 permitido nesta \u00e1rea. Ent\u00e3o isso se chama autoriza\u00e7\u00e3o. Assim, voc\u00ea est\u00e1 autorizado a entrar, mas depois de entrar em restaurante voc\u00ea n\u00e3o est\u00e1 autorizado a entrar em algumas \u00e1reas e n\u00e3o est\u00e1 autorizado a acessar alguma outra \u00e1rea. Ent\u00e3o \u00e9 isso que \u00e9 autoriza\u00e7\u00e3o.<\/p>\n
Agora, quando se trata de um site, qualquer pessoa pode entrar em uma p\u00e1gina<\/a> de login de site p\u00fablico. O mesmo que qualquer um pode entrar em um restaurante. Ningu\u00e9m vai impedi-lo. Quando voc\u00ea faz login com o nome de usu\u00e1rio<\/a> e a senha do seu site, voc\u00ea \u00e9 autenticado e pode entrar no site. Da mesma forma que voc\u00ea acessou uma mesa privada reservada em um restaurante usando uma reserva. Mas depois de entrar, e depois da autentica\u00e7\u00e3o, voc\u00ea pode acessar algumas se\u00e7\u00f5es, mas voc\u00ea pode n\u00e3o ser capaz de acessar algumas outras se\u00e7\u00f5es que s\u00e3o como se\u00e7\u00f5es administrativas do site. Portanto, esta \u00e9 uma diferen\u00e7a muito b\u00e1sica entre autentica\u00e7\u00e3o e autoriza\u00e7\u00e3o.<\/p>\n Agora, de volta \u00e0 nossa pergunta. Sempre vemos autoriza\u00e7\u00e3o em uma API, por que isso? Se voc\u00ea olhar para a API, ela est\u00e1 apontando para um ponto final onde esse endere\u00e7o para uma determinada fun\u00e7\u00e3o ou recurso no aplicativo. Podemos dizer, por exemplo, um m\u00f3dulo no back-end do aplicativo. Quando voc\u00ea est\u00e1 realmente tentando acessar um determinado recurso sozinho no aplicativo, \u00e9 mais apropriado cham\u00e1-lo como autoriza\u00e7\u00e3o para voc\u00ea, embora haja autentica\u00e7\u00e3o para verificar sua identidade. O primeiro passo \u00e9 sempre a autentica\u00e7\u00e3o.<\/p>\n <\/p>\n Uma vez que cobrimos a diferen\u00e7a entre autentica\u00e7\u00e3o e autoriza\u00e7\u00e3o, agora discutiremos diferentes tipos de autentica\u00e7\u00f5es de API. Os m\u00e9todos de autentica\u00e7\u00e3o da API s\u00e3o variados com base na t\u00e9cnica que eles usam. As autentica\u00e7\u00f5es s\u00e3o muito importantes porque est\u00e3o diretamente relacionadas com a seguran\u00e7a do seu sistema. \u00c9 por isso que a prioridade sempre vai para a autentica\u00e7\u00e3o HTTP em qualquer sistema.<\/p>\n Destacaremos cinco mecanismos principais de adi\u00e7\u00e3o de seguran\u00e7a a uma API \u2014 Basic, API Key, Bearer, OAuth1.0\/OAuth 2.0 e Connect OpenID. Identificaremos o que eles fazem, como funcionam, e vantagens e desvantagens de cada abordagem. Finalmente, demonstraremos testes de carga de uma API que requer autentica\u00e7\u00e3o usando o LoadView<\/a>.<\/p>\n <\/p>\n A autentica\u00e7\u00e3o b\u00e1sica HTTP raramente \u00e9 usada pela ind\u00fastria de TI hoje em dia<\/a>, porque \u00e9 muito f\u00e1cil de ser hackeado, mas esse \u00e9 o m\u00e9todo mais f\u00e1cil de implementar. As APIs enviar\u00e3o um nome de usu\u00e1rio e senha ao longo do corpo. As credenciais ser\u00e3o codificadas com m\u00e9todo de criptografia, como base64;<\/em> isso converter\u00e1 o nome de usu\u00e1rio e a senha em formato criptografado para a transmiss\u00e3o.<\/p>\n Uma vez que usa o cabe\u00e7alho para transmiss\u00e3o de credenciais, n\u00e3o existem outras medidas de seguran\u00e7a complexas. Nem mesmo IDs de sess\u00e3o ou cookies.<\/p>\n <\/p>\n Autoriza\u00e7\u00e3o: B\u00e1sico Cg4sOnOlY8KyPQ==<\/em><\/p>\n <\/p>\n A autentica\u00e7\u00e3o de acesso ao digest\u00e3o \u00e9 mais complexa e avan\u00e7ada do que a autentica\u00e7\u00e3o b\u00e1sica. O Digest usa uma combina\u00e7\u00e3o da senha do usu\u00e1rio e outros atributos para criar um hash MD5. Isso ser\u00e1 ent\u00e3o enviado ao servidor para autentica\u00e7\u00e3o. \u00c9 mais avan\u00e7ado do que outros mecanismos de seguran\u00e7a desde que envia as credenciais como hash. Foi originalmente criado como parte da RFC 2069, melhorias de seguran\u00e7a foram adicionadas mais tarde na RFC 2617.<\/p>\n Na autentica\u00e7\u00e3o de digest\u00e3o, \u00e9 o servidor que descobre o cliente que est\u00e1 tentando acessar o recurso. O servidor<\/a> gerar\u00e1 um valor exclusivo, conhecido como “nonce”. Posteriormente, esse valor \u00fanico ser\u00e1 usado pelo solicitante de recursos para gerar um hash MD5, que ser\u00e1 verificado pelo servidor.<\/p>\n <\/p>\n As chaves de API s\u00e3o amplamente utilizadas em compara\u00e7\u00e3o com a autentica\u00e7\u00e3o b\u00e1sica hoje em dia. Voc\u00ea pode v\u00ea-lo em aplicativos m\u00f3veis, bem como aplica\u00e7\u00f5es web. As chaves de API foram criadas para resolver<\/a> as vulnerabilidades de seguran\u00e7a associadas ao mecanismo b\u00e1sico da API. Em uma chave de API, um valor \u00fanico \u00e9 gerado no lado do servidor uma vez que voc\u00ea autentica com seu nome de usu\u00e1rio e senha. Ele ser\u00e1 atribu\u00eddo ao usu\u00e1rio. Normalmente, esse valor \u00fanico \u00e9 gerado com base no endere\u00e7o IP e em diferentes atributos do usu\u00e1rio. Na maioria das vezes, os desenvolvedores enviar\u00e3o a chave API no cabe\u00e7alho de autoriza\u00e7\u00e3o.<\/p>\n <\/p>\n api_key: d670d200234faf5480a11529b01d732<\/em><\/p>\n H\u00e1 definitivamente muitas vantagens de usar uma chave de API, em compara\u00e7\u00e3o com todos os outros mecanismos de seguran\u00e7a. Acima de tudo, as chaves de API s\u00e3o simples com melhor seguran\u00e7a. A desvantagem \u00e9 que qualquer um pode pegar essa chave de seguran\u00e7a usando qualquer uma das ferramentas de farejador de rede. Isso pode levar a problemas de seguran\u00e7a de toda a aplica\u00e7\u00e3o.<\/p>\n <\/p>\n Portador significa “uma pessoa ou coisa que carrega ou segura alguma coisa.” Como o nome sugere, \u00e9 um esquema de autentica\u00e7\u00e3o HTTP que envolve tokens de seguran\u00e7a. O portador do token de seguran\u00e7a ter\u00e1 acesso a certas fun\u00e7\u00f5es ou URLs. O token portador geralmente ser\u00e1 gerado pelo servidor em resposta a uma solicita\u00e7\u00e3o de login do cliente. Uma vez que o usu\u00e1rio tenha o token portador do servidor, ele deve enviar o token juntamente com o cabe\u00e7alho de autoriza\u00e7\u00e3o ao fazer novas solicita\u00e7\u00f5es.<\/p>\n <\/p>\n autoriza\u00e7\u00e3o: <\/em><\/p>\n Portador eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy93cy8yMDA1LzA1L2lkZW50aXR5L2NsYWltcy9uYW1lIIINMUYZTU0NjUtNTRjZi00zTU2LTk2NDEtNDU4Njg0Yj VjNWQyIiwiZXhwIjoxNTkzOTY3ODQ0LCJpc3MiOiJodHRwOlxd3d3LnNvdWxib29rLm1lIiwiYXVkIjoiaHR0cDpcXHd3dy5zb3VsYm9vay5tZSJ9.adcAYn8U5tn68EVGUGPLYBKCGC8Ohgxm7p45tDnpXVc<\/em><\/p>\n Foi originalmente criado como parte do OAuth2.0 na RFC-6750. H\u00e1 definitivamente muitas vantagens de usar tokens portadores em compara\u00e7\u00e3o com todos os outros mecanismos de seguran\u00e7a. Os tokens dos portadores s\u00e3o melhores em termos de seguran\u00e7a.<\/p>\n <\/p>\n O OAuth \u00e9 um protocolo<\/a> mais seguro para autoriza\u00e7\u00e3o. O OAuth<\/a> fornece simplicidade ao mesmo tempo em que fornece fluxo de autoriza\u00e7\u00e3o para aplicativos. OAuth \u00e9 geralmente usado pelos usu\u00e1rios para fazer login em sites de terceiros usando suas contas google, Microsoft, Facebook, Slack, por exemplo, sem expor suas credenciais.<\/p>\n OAuth 1.0 \u00e9 suspeito de vulnerabilidades de seguran\u00e7a e n\u00e3o \u00e9 mais suportado. OAuth 2.0 est\u00e1 com recursos avan\u00e7ados de seguran\u00e7a e \u00e9 o melhor para identifica\u00e7\u00e3o e autentica\u00e7\u00e3o de contas de usu\u00e1rio pessoal. OAuth 2.0 permite que os usu\u00e1rios compartilhem seus atributos espec\u00edficos com um aplicativo, mantendo suas credenciais e outras informa\u00e7\u00f5es em segredo. OAuth 1.0 foi muito mais complicado e menos seguro que o OAuth 2.0. A maior mudan\u00e7a no OAuth2.0 \u00e9 que n\u00e3o h\u00e1 necessidade de assinar cada chamada com um hash com chave.<\/p>\n Basicamente, o OAuth consiste em dois tokens para fazer a verifica\u00e7\u00e3o; um token de autentica\u00e7\u00e3o e token de sess\u00e3o. Os tokens de autentica\u00e7\u00e3o funcionam como protocolos de seguran\u00e7a-chave da API, o aplicativo autentica para acessar dados do usu\u00e1rio. Os tokens de sess\u00e3o s\u00e3o usados para manter a sess\u00e3o do usu\u00e1rio e recuperar um novo token de autentica\u00e7\u00e3o se o token de sess\u00e3o expirar. OAuth 2.0 combina autentica\u00e7\u00e3o e autoriza\u00e7\u00e3o para permitir mais seguran\u00e7a ao aplicativo.<\/p>\n Em OAuth, o usu\u00e1rio acessar\u00e1 o aplicativo com credenciais. Em seguida, o aplicativo solicitar\u00e1 um token de autentica\u00e7\u00e3o. O solicitante enviar\u00e1 essa solicita\u00e7\u00e3o para um servidor de autentica\u00e7\u00e3o, o que permitir\u00e1 essa autentica\u00e7\u00e3o se as credenciais estiverem corretas. Este token de autentica\u00e7\u00e3o pode ser verificado a qualquer momento, independente do usu\u00e1rio. Isso far\u00e1 do OAuth um mecanismo muito mais seguro do que as outras autentica\u00e7\u00f5es HTTP. Uma das principais desvantagens da OAuth \u00e9 a complexidade de implementar. Voc\u00ea deve ter um conhecimento s\u00f3lido no fluxo OAuth para integr\u00e1-lo com sua aplica\u00e7\u00e3o.<\/p>\n <\/p>\n OpenID Connect \u00e9 uma extens\u00e3o do protocolo OAuth 2.0. Verifica a identidade do cliente com base na autentica\u00e7\u00e3o realizada por um servidor de autoriza\u00e7\u00e3o. Al\u00e9m disso, ele pode obter informa\u00e7\u00f5es do perfil do usu\u00e1rio sobre o cliente. O Connect OpenID realmente resolve muitas desvantagens do OAuth 2.0 e fornece uma solu\u00e7\u00e3o melhor para usu\u00e1rios finais e desenvolvedores.<\/p>\n <\/p>\n A autentica\u00e7\u00e3o b\u00e1sica HTTP \u00e9 a mais f\u00e1cil de implementar em seu aplicativo, mas tamb\u00e9m n\u00e3o \u00e9 segura. As credenciais s\u00e3o codificadas, mas s\u00e3o enviadas como texto simples. A autentica\u00e7\u00e3o de digest\u00e3o melhora na autentica\u00e7\u00e3o b\u00e1sica enviando dados em formato hashed. Mas o hash do algoritmo MD5 n\u00e3o \u00e9 complexo e pode ser hackeado muito facilmente. As chaves de API e o portador s\u00e3o quase semelhantes e proporcionam uma melhor seguran\u00e7a que acima.<\/p>\n O protocolo OAuth garante que nenhum hacker possa obter informa\u00e7\u00f5es do cliente. Nem mesmo o aplicativo consegue obter as credenciais de perfil do cliente e informa\u00e7\u00f5es privadas. O OpenID Connect estabelece protocolos para que os aplicativos acessem os atributos do cliente usando a API RESTful<\/a>. O OpenID Connect amplia o fluxo de tokens de autoriza\u00e7\u00e3o OAuth 2.0 introduzindo novos tokens. Basicamente, o OpenID Connect \u00e9 realizado como uma extens\u00e3o do OAuth 2.0.<\/p>\n <\/p>\n Nesta se\u00e7\u00e3o, vamos implementar a autentica\u00e7\u00e3o http api usando o LoadView. O LoadView permite que voc\u00ea fa\u00e7a essas tarefas de forma muito f\u00e1cil e eficiente. O Load View oferece duas op\u00e7\u00f5es para testes de carga de autentica\u00e7\u00e3o de API:<\/p>\n <\/p>\n Se voc\u00ea tiver acesso ao aplicativo, podemos obter a solicita\u00e7\u00e3o de API usando qualquer ferramenta de rede. Este \u00e9 o m\u00e9todo mais simples. Mostraremos uma demonstra\u00e7\u00e3o r\u00e1pida para configurar cada um dos mecanismos de autentica\u00e7\u00e3o HTTP acima usando o LoadView<\/p>\n Nota: Voc\u00ea pode obter detalhes de solicita\u00e7\u00e3o do servidor API e detalhes de dados do corpo de sua equipe de desenvolvimento ou captur\u00e1-lo usando qualquer ferramenta de farejador de rede.<\/em><\/p>\n <\/p>\n A pr\u00f3xima tela pedir\u00e1 que voc\u00ea configure sua API. Aqui vamos mostrar como voc\u00ea pode configurar diferentes mecanismos de autentica\u00e7\u00e3o HTTP no LoadView.<\/p>\n Autentica\u00e7\u00e3o B\u00e1sica<\/strong><\/p>\n <\/p>\n Chaves de API<\/strong><\/p>\n <\/p>\n Token portador<\/strong><\/p>\n <\/p>\n OAuth 2.0<\/strong><\/p>\n OAuth 2.0 e o Open ID Connect s\u00e3o mais complexos de configurar. Vou te mostrar demo para OAuth 2.0. H\u00e1 uma maneira f\u00e1cil de fazer autentica\u00e7\u00e3o OAuth 2.0 que explicarei ap\u00f3s esta se\u00e7\u00e3o.<\/p>\n <\/p>\n Configure os detalhes do servidor de autentica\u00e7\u00e3o do OAuth.<\/p>\n <\/p>\n Digite credenciais e clique em login. O servidor de autentica\u00e7\u00e3o redireciona o usu\u00e1rio para o seu site com um c\u00f3digo como par\u00e2metro url.<\/p>\n <\/p>\n <\/p>\n O servidor API pede informa\u00e7\u00f5es ao servidor de autentica\u00e7\u00e3o.<\/p>\n <\/p>\n Os servidores de API identificam o usu\u00e1rio e respondem com um token de acesso. Em seguida, o usu\u00e1rio envia o token de acesso ao servidor API em cada solicita\u00e7\u00e3o. O servidor API valida e d\u00e1 acesso ao aplicativo.<\/p>\n <\/p>\n <\/p>\n Se a primeira op\u00e7\u00e3o n\u00e3o for vi\u00e1vel, voc\u00ea pode grav\u00e1-la usando a ferramenta de grava\u00e7\u00e3o EveryStep Web Recorder.<\/a> Voc\u00ea pode acess\u00e1-lo pela web e usar o gravador \u00e9 mais f\u00e1cil e eficaz. Al\u00e9m disso, voc\u00ea n\u00e3o precisa aprender diferentes mecanismos de autentica\u00e7\u00e3o. Aqui vamos demonstrar como fazer testes de carga usando o LoadView e usando o EveryStep Web Recorder. O aplicativo est\u00e1 usando o OAuth 2.0 para autentica\u00e7\u00e3o.<\/p>\n <\/p>\n Fa\u00e7a login no LoadView e selecione um tipo de teste de<\/em>carga, selecione Aplicativos da Web<\/em>. Ou basta abrir o EveryStep Web Recorder,<\/a>digitar sua URL e come\u00e7ar a gravar.<\/p>\n <\/p>\n <\/p>\n <\/p>\n \u00c9 isso, \u00e9 isso. Voc\u00ea gravou autentica\u00e7\u00e3o de aplicativo, tendo OAuth 2.0. Reproduza o script gravado e certifique-se de que tudo est\u00e1 funcionando como esperado. N\u00e3o \u00e9 simples? Uma vez que a grava\u00e7\u00e3o \u00e9 feita, voc\u00ea pode passar para os pr\u00f3ximos passos para executar o teste de carga.<\/p>\n <\/p>\n Correlacionar mecanismos de autentica\u00e7\u00e3o HTTP n\u00e3o \u00e9 uma tarefa f\u00e1cil usando qualquer ferramenta de teste de desempenho. Voc\u00ea precisa ter experi\u00eancia pr\u00e1tica e profundo conhecimento sobre como o fluxo de autentica\u00e7\u00e3o funciona. Al\u00e9m disso, \u00e9 muito importante fazer testes de carga para sua funcionalidade de login. Se o seu m\u00f3dulo de login n\u00e3o for capaz de atender \u00e0 carga simult\u00e2nea esperada do usu\u00e1rio, ser\u00e1 uma grande perda para o seu neg\u00f3cio. O login do aplicativo \u00e9 uma parte cr\u00edtica da funcionalidade do seu aplicativo. <\/strong> Se voc\u00ea est\u00e1 procurando uma boa solu\u00e7\u00e3o de teste de desempenho de ponta a ponta para suas APIs da Web<\/a>, voc\u00ea definitivamente gostar\u00e1 do LoadView. V\u00e1 em frente e tente hoje!<\/a><\/p>\n[\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section]\n","protected":false},"excerpt":{"rendered":" Na economia atual impulsionada por TI, as APIs web est\u00e3o se tornando cada vez mais usadas em todo o mundo. Voc\u00ea provavelmente consumiu ou criou uma APIs voc\u00ea mesmo. As APIs lidam com enormes quantidades de dados \u2014 uma das principais preocupa\u00e7\u00f5es que a organiza\u00e7\u00e3o de servi\u00e7os de software est\u00e1 especificamente procurando para proteger esses […]<\/p>\n","protected":false},"author":5,"featured_media":21112,"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":[547,527,507],"tags":[528,518],"class_list":["post-21101","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-experiencia-do-usuario","category-teste-de-api","category-teste-de-desempenho","tag-teste-de-api","tag-teste-de-carga"],"yoast_head":"\nTipos de autentica\u00e7\u00f5es HTTP<\/h2>\n
Autentica\u00e7\u00e3o B\u00e1sica<\/h3>\n
Exemplo de autentica\u00e7\u00e3o b\u00e1sica em um cabe\u00e7alho de solicita\u00e7\u00e3o:<\/h4>\n
Autentica\u00e7\u00e3o de digest\u00e3o<\/h3>\n
Chaves de API<\/h3>\n
Exemplo de uma chave de API<\/h4>\n
portador<\/h3>\n
Exemplo de Autentica\u00e7\u00e3o portadora<\/h4>\n
OAuth 1.0 e OAuth 2.0<\/h3>\n
OpenID Connect<\/h3>\n
Qual \u00e9 o melhor protocolo de autentica\u00e7\u00e3o para usar?<\/h3>\n
Usando o LoadView para testar uma API que requer autentica\u00e7\u00e3o<\/h2>\n
Autentica\u00e7\u00e3o de API: Op\u00e7\u00e3o Um<\/h3>\n
\u00a0<\/h5>\n
Passo 1: Selecione um tipo de teste de carga<\/strong><\/h4>\n
Fa\u00e7a login no LoadView e selecione um tipo de teste de carga,<\/em>selecione HTTP\/S<\/em>.<\/h5>\n
![\"Selecione](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/Select-a-Load-Testing-Type-1024x459.png\")
<\/p>\nPasso 2: Configure sua API<\/strong><\/h4>\n
![\"Autentica\u00e7\u00e3o](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/Basic-Authentication-1024x466.png\")
<\/p>\n![\"Chaves](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/API-Keys-1024x465.png\")
<\/p>\n![\"Token](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/Bearer-Token-1024x461.png\")
<\/p>\nPasso 1: Servidor de Autentica\u00e7\u00e3o OAuth<\/strong><\/h5>\n
![\"Autentica\u00e7\u00e3o](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/OAuth-Authentication-1024x437.png\")
<\/p>\nPasso 2: Credenciais<\/strong><\/h5>\n
![\"Credenciais](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/OAuth-Authentication-Credentials-1024x462.png\")
<\/p>\nPasso 3: Informa\u00e7\u00f5es do servidor<\/strong><\/h5>\n
![\"Informa\u00e7\u00f5es](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/OAuth-Authentication-Server-Information-1024x457.png\")
<\/p>\nPasso 4: Token de acesso<\/strong><\/h5>\n
![\"Token](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/OAuth-Authentication-Access-Token-1024x449.png\")
<\/p>\nAutentica\u00e7\u00e3o de API: Op\u00e7\u00e3o Dois<\/h3>\n
Passo 1: Grave um novo roteiro<\/strong><\/h4>\n
![\"OAuth](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/OAuth-record-new-script-1024x445.jpg\")
<\/p>\nPasso 2: Navegue para funcionalidade de login<\/strong><\/h4>\n
![\"Sinal](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/OAuth-Sign-In-1024x447.png\")
<\/p>\n![\"Sinal](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/OAuth-Sign-In-Step-2-1024x449.png\")
<\/p>\nPensamentos Finais: Teste de carga APIs web que requerem autentica\u00e7\u00e3o<\/h2>\n