As APIs lidam com enormes quantidades de dados de um tipo amplamente variado – consequentemente, uma das principais preocupações de qualquer provedor de dados é como proteger especificamente esses dados. A ideia de que os dados devem ser secretos, que devem ser inalterados e que devem estar disponíveis para manipulação é a chave para qualquer conversa sobre gerenciamento e manuseio de dados da API.

Hoje, vamos falar sobre 3 Métodos de Autenticação de APIs  autenticação . Embora seja um tópico frequentemente discutido, vale a pena repetir para esclarecer exatamente o que é, o que não é e como funciona.

Destacaremos três métodos principais de adicionar segurança a uma API – autenticação básica HTTP , chaves de API e OAuth . Identificaremos os prós e os contras de cada abordagem da autenticação e, finalmente, recomendaremos a melhor maneira de a maioria dos provedores aproveitar esse poder.

Autenticação vs Autorização

Antes de nos aprofundarmos neste tópico, precisamos primeiro definir o que realmente é a autenticação e, mais importante, o que não é. Por mais que a autenticação conduza a Internet moderna, o tópico geralmente é confundido com um termo intimamente relacionado: autorização .

As duas funções geralmente estão ligadas em soluções únicas – na verdade, uma das soluções que discutiremos daqui a pouco é um sistema híbrido de autenticação e autorização. Como tal, e devido às suas semelhanças na aplicação funcional, é bastante fácil confundir esses dois elementos.

A maneira mais fácil de dividir autorização e autenticação é perguntar: o que eles realmente provam?

Em termos simples, autenticação é quando uma entidade prova uma identidade . Em outras palavras, a autenticação prova que você é quem diz ser.

 É como ter um cartão de identificação – um item fornecido por uma autoridade confiável que o solicitante, como um policial, pode usar como evidência que sugere que você é de fato quem você diz ser.

Autorização é um conceito totalmente diferente, embora certamente esteja intimamente relacionado. Em termos simples, a autorização é quando uma entidade comprova o direito de acesso . 

Em outras palavras, a autorização prova que você tem o direito de fazer uma solicitação. 

Quando você tenta ir aos bastidores de um concerto ou evento, não precisa necessariamente provar que é quem diz ser – você fornece o ingresso , o que é de fato uma prova de que você tem o direito de estar onde está ‘ está tentando entrar.

Considere por um momento uma carteira de motorista. Em muitos países, uma carteira de motorista prova que você é quem diz ser através de uma foto ou outro elemento certificado e depois vai mais longe para provar que você tem o direito de dirigir a classe de veículo que está dirigindo. 

Nesse caso, temos autenticação e autorização – e em muitas soluções de API, temos sistemas que fornecem um pedaço de código que autentica o usuário e comprova sua autorização. Nesse caso, temos soluções híbridas .

Portanto, no futuro, é importante lembrar que o que estamos falando aqui é um sistema que comprova sua identidade – nada mais, nada menos.Relacionado: Como controlar a identidade do usuário nos microsserviços

Métodos comuns de autenticação de API

Embora existam tantos métodos de autenticação quanto sistemas que os utilizam, eles são amplamente variações de algumas das principais abordagens. Essas abordagens quase sempre foram desenvolvidas para resolver limitações nas primeiras comunicações e sistemas de Internet e, como tal, geralmente usam abordagens arquiteturais amplas existentes com implementações novas para permitir a autenticação.

Autenticação básica HTTP

A autenticação básica HTTP raramente é recomendada devido às vulnerabilidades de segurança inerentes.

Uma solução é a autenticação básica HTTP . Nessa abordagem, um agente de usuário HTTP simplesmente fornece um nome de usuário e senha para provar sua autenticação. 

Essa abordagem não requer cookies, IDs de sessão, páginas de login e outras soluções especiais e, como usa o próprio cabeçalho HTTP , não há necessidade de handshakes ou outros sistemas de resposta complexos.

O problema é que, a menos que o processo seja rigorosamente aplicado durante todo o ciclo de dados ao SSL para segurança, a autenticação é transmitida em aberto em linhas não seguras. 

Isso se presta a ataques intermediários , onde um usuário pode simplesmente capturar os dados de login e autenticar através de um cabeçalho HTTP copy-cat anexado a um pacote malicioso.

Além disso, mesmo que o SSL seja imposto, isso resulta em uma  redução no tempo de resposta. E mesmo ignorando que, em sua forma básica, o HTTP não é criptografado de forma alguma. Ele é encapsulado em base64 e é frequentemente proclamado erroneamente como criptografado devido a isso.

A autenticação básica HTTP tem seu lugar. Em uma rede interna , especialmente em situações de IoT em que a velocidade não é essencial, ter um sistema de autenticação básica HTTP é aceitável como um equilíbrio entre o custo de implementação e a função real. 

Como uma solução de autenticação geral, no entanto, a autenticação básica HTTP raramente deve ser usada em sua forma básica .

Chaves de API

As chaves de API são um padrão do setor, mas não devem ser consideradas uma medida de segurança holística.

As chaves de API foram criadas como uma correção para os problemas iniciais da autenticação básica HTTP e outros sistemas desse tipo. Nesta abordagem, um valor gerado exclusivo é atribuído a cada usuário iniciante, significando que o usuário é conhecido.

Quando o usuário tenta entrar novamente no sistema, sua chave exclusiva (às vezes gerada a partir de sua combinação de hardware e dados IP, e outras vezes gerada aleatoriamente pelo servidor que os conhece) é usada para provar que é o mesmo usuário de antes .

Por um lado, isso é muito rápido . A capacidade de provar a identidade uma vez e seguir em frente é muito ágil e é por isso que tem sido usada há muitos anos como uma abordagem padrão para muitos provedores de API. Além disso, é muito fácil configurar o próprio sistema, e controlar essas chaves uma vez geradas é ainda mais fácil.

Isso também permite que os sistemas limpem as chaves, removendo a autenticação após o fato e negando a entrada em qualquer sistema que tente usar uma chave removida.

O problema, no entanto, é que as chaves de API são frequentemente usadas para o que não são indicadas – uma chave de API não é um método de autorização , é um método de autenticação. 

Como qualquer pessoa que solicite um serviço transmite sua chave, em teoria, essa chave pode ser escolhida tão facilmente quanto qualquer transmissão de rede e, se algum ponto de toda a rede for inseguro, toda a rede será exposta. 

Isso torna difícil recomendar as chaves de API – geralmente mal utilizadas e fundamentalmente inseguras ; elas ainda têm seu lugar quando adequadamente protegidas e protegidas por sistemas de autorização.

OAuth

Assim, o OAuth combina autenticação e autorização para permitir escopo e controle de validade mais sofisticados.

Tecnicamente, o OAuth não é um método de autenticação, mas um método de autenticação e autorização . Quando o OAuth é usado apenas para autenticação, é chamado de “pseudo-autenticação”.

Nesta abordagem, o usuário efetua login no sistema. Esse sistema solicitará autenticação, geralmente na forma de um token . O usuário encaminhará essa solicitação para um servidor de autenticação, que rejeitará ou permitirá essa autenticação. A partir daqui, o token é fornecido ao usuário e depois ao solicitante.

Esse token pode ser verificado a qualquer momento, independentemente do usuário, pelo solicitante para validação, e pode ser usado ao longo do tempo com escopo e idade de validade estritamente limitados.

Este é fundamentalmente um sistema muito mais seguro e poderoso do que as outras abordagens, principalmente porque permite o estabelecimento suave de escopo (ou seja, quais sistemas a chave permite que o usuário se autentique) e validade (o que significa que a chave não possui para ser propositalmente revogado pelo sistema, ele se tornará obsoleto automaticamente com o tempo).

Como em tudo, existem alguns prós e contras importantes nessa abordagem. Por um lado, é claramente superior quando se trata do nível de segurança que pode oferecer e, por esse motivo, o OAuth está rapidamente se tornando a opção de fato para quem escolhe evitar as chaves da API .

Por outro lado, o uso do OAuth somente para autenticação está ignorando tudo o mais que o OAuth tem a oferecer – seria como dirigir uma Ferrari como motorista do dia a dia e nunca exceder os limites de velocidade residencial.

A melhor opção

Então, dessas três abordagens, duas mais gerais e uma mais específica, qual é a melhor? Essa é uma pergunta difícil de responder, e a resposta em si depende em grande parte das suas situações. 

Embora o vencedor claro das três abordagens seja o OAuth , há alguns casos de uso nos quais as chaves de API ou a autenticação básica HTTP podem ser apropriadas.

Dito isto, esses casos de uso são poucos e distantes entre si; portanto, é muito difícil argumentar contra o OAuth no final do dia. O OAuth oferece muitos benefícios , da facilidade de uso a um módulo de sistema federado, e o mais importante oferece escalabilidade de segurança – os provedores podem estar apenas buscando autenticação no momento, mas possuem um sistema que oferece suporte nativo a forte autorização, além disso. nos métodos de autenticação é muito valioso e diminui o custo de implementação a longo prazo.

FONTE:Nordic APIs