Na economia atual impulsionada por TI, as APIs web estão se tornando cada vez mais usadas em todo o mundo. Você provavelmente consumiu ou criou uma APIs você mesmo. As APIs lidam com enormes quantidades de dados — uma das principais preocupações que a organização de serviços de software está especificamente procurando para proteger esses dados. A ideia é que os dados sejam estáveis e protegidos e possam ser acessados apenas por usuários pretendidos. Tempo, velocidade e desempenho também importam para as APIs. Aqui neste artigo, vamos discutir diferentes métodos de autenticação e autorização de API que são amplamente utilizados por organizações de TI em todo o mundo.
Autenticação vs. Autorização
Se você já trabalhou em uma API, você sempre verá apenas cabeçalhos de autorização, não cabeçalhos de autenticação. Você já se perguntou por quê? Basta usar qualquer ferramenta de detecção de rede, como o Fiddler/Wireshark, ou usar uma ferramenta de teste de API e verificar a API do seu aplicativo. Se você ver os cabeçalhos ou o corpo de uma API, sua solicitação de API sempre encontrará autorização. Então, antes de explicar por que as APIs só têm autorização e não autenticação, vamos primeiro explicar a diferença entre autenticação e autorização.
autenticação
A autenticação não é nada além de validar um usuário se ele é a pessoa certa para usar esse serviço. Vamos explicar mais adiante com um exemplo simples. Digamos que você está visitando um restaurante em sua cidade com sua família. Você abre a porta do restaurante e é bem-vindo pelo gerente. Mas você não quer sentar em um restaurante público no restaurante, você quer sentar em um quarto privado com a família e você tem que ter uma reserva para isso. Você avisa o gerente e eles confirmam que você tem uma reserva, permitindo que você se sente na seção privada do restaurante reservada para as famílias. Então, isso é o que chamamos de autenticação. Você foi autorizado pelo gerente do restaurante a sentar-se com sua família em um lugar privado com uma reserva válida. Podemos dizer que a reserva é chamada de chave de autenticação.
autorização
Agora, você pode entrar no quarto privado e pode usar os serviços reservados para restaurantes privados, etc. Você está autorizado a fazer tudo isso, mas se você entrar na cozinha do restaurante e abrir sua geladeira eles podem dizer que você não é permitido nesta área. Então isso se chama autorização. Assim, você está autorizado a entrar, mas depois de entrar em restaurante você não está autorizado a entrar em algumas áreas e não está autorizado a acessar alguma outra área. Então é isso que é autorização.
Agora, quando se trata de um site, qualquer pessoa pode entrar em uma página de login de site público. O mesmo que qualquer um pode entrar em um restaurante. Ninguém vai impedi-lo. Quando você faz login com o nome de usuário e a senha do seu site, você é autenticado e pode entrar no site. Da mesma forma que você acessou uma mesa privada reservada em um restaurante usando uma reserva. Mas depois de entrar, e depois da autenticação, você pode acessar algumas seções, mas você pode não ser capaz de acessar algumas outras seções que são como seções administrativas do site. Portanto, esta é uma diferença muito básica entre autenticação e autorização.
Agora, de volta à nossa pergunta. Sempre vemos autorização em uma API, por que isso? Se você olhar para a API, ela está apontando para um ponto final onde esse endereço para uma determinada função ou recurso no aplicativo. Podemos dizer, por exemplo, um módulo no back-end do aplicativo. Quando você está realmente tentando acessar um determinado recurso sozinho no aplicativo, é mais apropriado chamá-lo como autorização para você, embora haja autenticação para verificar sua identidade. O primeiro passo é sempre a autenticação.
Tipos de autenticações HTTP
Uma vez que cobrimos a diferença entre autenticação e autorização, agora discutiremos diferentes tipos de autenticações de API. Os métodos de autenticação da API são variados com base na técnica que eles usam. As autenticações são muito importantes porque estão diretamente relacionadas com a segurança do seu sistema. É por isso que a prioridade sempre vai para a autenticação HTTP em qualquer sistema.
Destacaremos cinco mecanismos principais de adição de segurança a uma API — 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ção usando o LoadView.
Autenticação Básica
A autenticação básica HTTP raramente é usada pela indústria de TI hoje em dia, porque é muito fácil de ser hackeado, mas esse é o método mais fácil de implementar. As APIs enviarão um nome de usuário e senha ao longo do corpo. As credenciais serão codificadas com método de criptografia, como base64; isso converterá o nome de usuário e a senha em formato criptografado para a transmissão.
Uma vez que usa o cabeçalho para transmissão de credenciais, não existem outras medidas de segurança complexas. Nem mesmo IDs de sessão ou cookies.
Exemplo de autenticação básica em um cabeçalho de solicitação:
Autorização: Básico Cg4sOnOlY8KyPQ==
Autenticação de digestão
A autenticação de acesso ao digestão é mais complexa e avançada do que a autenticação básica. O Digest usa uma combinação da senha do usuário e outros atributos para criar um hash MD5. Isso será então enviado ao servidor para autenticação. É mais avançado do que outros mecanismos de segurança desde que envia as credenciais como hash. Foi originalmente criado como parte da RFC 2069, melhorias de segurança foram adicionadas mais tarde na RFC 2617.
Na autenticação de digestão, é o servidor que descobre o cliente que está tentando acessar o recurso. O servidor gerará um valor exclusivo, conhecido como “nonce”. Posteriormente, esse valor único será usado pelo solicitante de recursos para gerar um hash MD5, que será verificado pelo servidor.
Chaves de API
As chaves de API são amplamente utilizadas em comparação com a autenticação básica hoje em dia. Você pode vê-lo em aplicativos móveis, bem como aplicações web. As chaves de API foram criadas para resolver as vulnerabilidades de segurança associadas ao mecanismo básico da API. Em uma chave de API, um valor único é gerado no lado do servidor uma vez que você autentica com seu nome de usuário e senha. Ele será atribuído ao usuário. Normalmente, esse valor único é gerado com base no endereço IP e em diferentes atributos do usuário. Na maioria das vezes, os desenvolvedores enviarão a chave API no cabeçalho de autorização.
Exemplo de uma chave de API
api_key: d670d200234faf5480a11529b01d732
Há definitivamente muitas vantagens de usar uma chave de API, em comparação com todos os outros mecanismos de segurança. Acima de tudo, as chaves de API são simples com melhor segurança. A desvantagem é que qualquer um pode pegar essa chave de segurança usando qualquer uma das ferramentas de farejador de rede. Isso pode levar a problemas de segurança de toda a aplicação.
portador
Portador significa “uma pessoa ou coisa que carrega ou segura alguma coisa.” Como o nome sugere, é um esquema de autenticação HTTP que envolve tokens de segurança. O portador do token de segurança terá acesso a certas funções ou URLs. O token portador geralmente será gerado pelo servidor em resposta a uma solicitação de login do cliente. Uma vez que o usuário tenha o token portador do servidor, ele deve enviar o token juntamente com o cabeçalho de autorização ao fazer novas solicitações.
Exemplo de Autenticação portadora
autorização:
Portador eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy93cy8yMDA1LzA1L2lkZW50aXR5L2NsYWltcy9uYW1lIIINMUYZTU0NjUtNTRjZi00zTU2LTk2NDEtNDU4Njg0Yj VjNWQyIiwiZXhwIjoxNTkzOTY3ODQ0LCJpc3MiOiJodHRwOlxd3d3LnNvdWxib29rLm1lIiwiYXVkIjoiaHR0cDpcXHd3dy5zb3VsYm9vay5tZSJ9.adcAYn8U5tn68EVGUGPLYBKCGC8Ohgxm7p45tDnpXVc
Foi originalmente criado como parte do OAuth2.0 na RFC-6750. Há definitivamente muitas vantagens de usar tokens portadores em comparação com todos os outros mecanismos de segurança. Os tokens dos portadores são melhores em termos de segurança.
OAuth 1.0 e OAuth 2.0
O OAuth é um protocolo mais seguro para autorização. O OAuth fornece simplicidade ao mesmo tempo em que fornece fluxo de autorização para aplicativos. OAuth é geralmente usado pelos usuários para fazer login em sites de terceiros usando suas contas google, Microsoft, Facebook, Slack, por exemplo, sem expor suas credenciais.
OAuth 1.0 é suspeito de vulnerabilidades de segurança e não é mais suportado. OAuth 2.0 está com recursos avançados de segurança e é o melhor para identificação e autenticação de contas de usuário pessoal. OAuth 2.0 permite que os usuários compartilhem seus atributos específicos com um aplicativo, mantendo suas credenciais e outras informações em segredo. OAuth 1.0 foi muito mais complicado e menos seguro que o OAuth 2.0. A maior mudança no OAuth2.0 é que não há necessidade de assinar cada chamada com um hash com chave.
Basicamente, o OAuth consiste em dois tokens para fazer a verificação; um token de autenticação e token de sessão. Os tokens de autenticação funcionam como protocolos de segurança-chave da API, o aplicativo autentica para acessar dados do usuário. Os tokens de sessão são usados para manter a sessão do usuário e recuperar um novo token de autenticação se o token de sessão expirar. OAuth 2.0 combina autenticação e autorização para permitir mais segurança ao aplicativo.
Em OAuth, o usuário acessará o aplicativo com credenciais. Em seguida, o aplicativo solicitará um token de autenticação. O solicitante enviará essa solicitação para um servidor de autenticação, o que permitirá essa autenticação se as credenciais estiverem corretas. Este token de autenticação pode ser verificado a qualquer momento, independente do usuário. Isso fará do OAuth um mecanismo muito mais seguro do que as outras autenticações HTTP. Uma das principais desvantagens da OAuth é a complexidade de implementar. Você deve ter um conhecimento sólido no fluxo OAuth para integrá-lo com sua aplicação.
OpenID Connect
OpenID Connect é uma extensão do protocolo OAuth 2.0. Verifica a identidade do cliente com base na autenticação realizada por um servidor de autorização. Além disso, ele pode obter informações do perfil do usuário sobre o cliente. O Connect OpenID realmente resolve muitas desvantagens do OAuth 2.0 e fornece uma solução melhor para usuários finais e desenvolvedores.
Qual é o melhor protocolo de autenticação para usar?
A autenticação básica HTTP é a mais fácil de implementar em seu aplicativo, mas também não é segura. As credenciais são codificadas, mas são enviadas como texto simples. A autenticação de digestão melhora na autenticação básica enviando dados em formato hashed. Mas o hash do algoritmo MD5 não é complexo e pode ser hackeado muito facilmente. As chaves de API e o portador são quase semelhantes e proporcionam uma melhor segurança que acima.
O protocolo OAuth garante que nenhum hacker possa obter informações do cliente. Nem mesmo o aplicativo consegue obter as credenciais de perfil do cliente e informações privadas. O OpenID Connect estabelece protocolos para que os aplicativos acessem os atributos do cliente usando a API RESTful. O OpenID Connect amplia o fluxo de tokens de autorização OAuth 2.0 introduzindo novos tokens. Basicamente, o OpenID Connect é realizado como uma extensão do OAuth 2.0.
Usando o LoadView para testar uma API que requer autenticação
Nesta seção, vamos implementar a autenticação http api usando o LoadView. O LoadView permite que você faça essas tarefas de forma muito fácil e eficiente. O Load View oferece duas opções para testes de carga de autenticação de API:
Autenticação de API: Opção Um
Se você tiver acesso ao aplicativo, podemos obter a solicitação de API usando qualquer ferramenta de rede. Este é o método mais simples. Mostraremos uma demonstração rápida para configurar cada um dos mecanismos de autenticação HTTP acima usando o LoadView
Nota: Você pode obter detalhes de solicitação do servidor API e detalhes de dados do corpo de sua equipe de desenvolvimento ou capturá-lo usando qualquer ferramenta de farejador de rede.
Passo 1: Selecione um tipo de teste de carga
Faça login no LoadView e selecione um tipo de teste de carga,selecione HTTP/S.
Passo 2: Configure sua API
A próxima tela pedirá que você configure sua API. Aqui vamos mostrar como você pode configurar diferentes mecanismos de autenticação HTTP no LoadView.
Autenticação Básica
Chaves de API
Token portador
OAuth 2.0
OAuth 2.0 e o Open ID Connect são mais complexos de configurar. Vou te mostrar demo para OAuth 2.0. Há uma maneira fácil de fazer autenticação OAuth 2.0 que explicarei após esta seção.
Passo 1: Servidor de Autenticação OAuth
Configure os detalhes do servidor de autenticação do OAuth.
Passo 2: Credenciais
Digite credenciais e clique em login. O servidor de autenticação redireciona o usuário para o seu site com um código como parâmetro url.
Passo 3: Informações do servidor
O servidor API pede informações ao servidor de autenticação.
Passo 4: Token de acesso
Os servidores de API identificam o usuário e respondem com um token de acesso. Em seguida, o usuário envia o token de acesso ao servidor API em cada solicitação. O servidor API valida e dá acesso ao aplicativo.
Autenticação de API: Opção Dois
Se a primeira opção não for viável, você pode gravá-la usando a ferramenta de gravação EveryStep Web Recorder. Você pode acessá-lo pela web e usar o gravador é mais fácil e eficaz. Além disso, você não precisa aprender diferentes mecanismos de autenticação. Aqui vamos demonstrar como fazer testes de carga usando o LoadView e usando o EveryStep Web Recorder. O aplicativo está usando o OAuth 2.0 para autenticação.
Passo 1: Grave um novo roteiro
Faça login no LoadView e selecione um tipo de teste decarga, selecione Aplicativos da Web. Ou basta abrir o EveryStep Web Recorder,digitar sua URL e começar a gravar.
Passo 2: Navegue para funcionalidade de login
É isso, é isso. Você gravou autenticação de aplicativo, tendo OAuth 2.0. Reproduza o script gravado e certifique-se de que tudo está funcionando como esperado. Não é simples? Uma vez que a gravação é feita, você pode passar para os próximos passos para executar o teste de carga.
Pensamentos Finais: Teste de carga APIs web que requerem autenticação
Correlacionar mecanismos de autenticação HTTP não é uma tarefa fácil usando qualquer ferramenta de teste de desempenho. Você precisa ter experiência prática e profundo conhecimento sobre como o fluxo de autenticação funciona. Além disso, é muito importante fazer testes de carga para sua funcionalidade de login. Se o seu módulo de login não for capaz de atender à carga simultânea esperada do usuário, será uma grande perda para o seu negócio. O login do aplicativo é uma parte crítica da funcionalidade do seu aplicativo. Se você está procurando uma boa solução de teste de desempenho de ponta a ponta para suas APIs da Web, você definitivamente gostará do LoadView. Vá em frente e tente hoje!