Chaves de API vs autenticação HTTP vs OAuth em uma API RESTful


101

Estou trabalhando na construção de uma API RESTful para um dos aplicativos que mantenho. No momento, estamos procurando incorporar várias coisas nele que requerem acesso mais controlado e segurança. Enquanto pesquisava sobre como proteger a API, encontrei algumas opiniões diferentes sobre o formulário a ser usado. Eu vi alguns recursos dizerem que HTTP-Auth é o caminho a percorrer, enquanto outros preferem chaves de API e até mesmo outros (incluindo as perguntas que encontrei aqui no SO) juram pelo OAuth.

Então, é claro, aqueles que preferem, digamos, chaves de API, dizem que o OAuth foi projetado para aplicativos que obtêm acesso em nome de um usuário (pelo que entendi, como entrar em um site que não seja do Facebook usando sua conta do Facebook), e não para um usuário acessando diretamente os recursos em um site no qual se inscreveu especificamente (como o cliente oficial do Twitter acessando os servidores do Twitter). No entanto, as recomendações para OAuth parecem ser até mesmo para as necessidades de autenticação mais básicas.

Minha pergunta, então, é - presumindo que tudo seja feito por HTTPS, quais são algumas das diferenças práticas entre os três? Quando um deve ser considerado sobre os outros?


com o que você acabou indo?
Irwin

@Irwin - Eu fiz essa pergunta há algum tempo e desde então mudei do projeto que exigia isso, mas acabei usando uma combinação de chaves API e senha gerada (que os usuários nunca veem), que são enviadas usando autenticação HTTP.
Shauna

Respostas:


67

Isso depende de suas necessidades. Você precisa:

  • Identidade - quem afirma estar fazendo uma solicitação de API?
  • Autenticação - eles são realmente quem dizem ser?
  • Autorização - eles podem fazer o que estão tentando fazer?

ou todos os três?

Se você precisa apenas identificar o chamador para controlar o volume ou o número de chamadas de API, use uma chave de API simples. Lembre-se de que, se o usuário para o qual você emitiu a chave API compartilhá-la com outra pessoa, eles também poderão chamar sua API.

Mas, se você também precisar de autorização, ou seja, fornecer acesso apenas a determinados recursos com base no chamador da API e, em seguida, use oAuth.

Aqui está uma boa descrição: http://www.srimax.com/index.php/do-you-need-api-keys-api-identity-vs-authorization/


com "certos recursos", você quer dizer "certas chamadas de API" ou "certos registros de banco de dados" ou ambos?
Magne

Principalmente registros de banco de dados (ou qualquer coisa que revele o estado protegido ou modifique o estado). Mas também pode ser algo como um recurso premium (como a execução de um algoritmo em uma nuvem) que realmente não muda nada no banco de dados, mas usa recursos do sistema e deve estar disponível apenas para indivíduos autorizados.
Sid

@Sid Estou trabalhando em um aplicativo que usa OAuth para registrar usuários que se inscrevem no Facebook ou LinkedIn. Além disso, estamos abrindo nossa API para outros serviços de gerenciamento de dados. Nesse caso, você recomendaria o OAuth para autenticação do usuário e uma chave de API ou combinação de nome de usuário e senha (como no artigo ao qual você ligou) para serviços que acessam a API? OAuth e a chave de API são usados ​​para finalidades diferentes, certo?
Tom Doe

@TomDoe Olá Tom - Sim, faz sentido. Você provavelmente deseja usar OAuth2 agora. Se o seu servidor estiver em Python (Django ou Flask), dê uma olhada em github.com/omab/python-social-auth
Sid

Não entendo como uma chave de API não pode fornecer essas três coisas. A identidade e a autenticação são baseadas em "você conhece um segredo específico?" (a menos que você introduza 2FA, que é um tópico separado). Se eu der a chave API muito longa do usuário 5, isso afirma e prova que sou o usuário 5, pelo menos tão bem quanto um nome de usuário / senha faria. E não há razão para que não seja possível atribuir permissões diferentes a chaves de API diferentes. Certo? O que estou perdendo aqui?
Nathan Long de

3

Chaves de API ou mesmo tokens se enquadram na categoria de mecanismos de autenticação e autorização diretos, pois concedem acesso a recursos expostos das APIs REST. Esses mecanismos diretos podem ser usados ​​em casos de uso de delegação.

Para obter acesso a um recurso ou conjunto de recursos expostos por terminais REST, é necessário verificar os privilégios do solicitante de acordo com sua identidade. A primeira etapa do fluxo de trabalho é, então, verificar a identidade por meio da autenticação da solicitação; etapa sucessiva é verificar a identidade em relação a um conjunto de regras definidas para autorizar o nível de acesso (ou seja, leitura, gravação ou leitura / gravação). Uma vez que essas etapas são cumpridas, uma preocupação adicional típica é a taxa de solicitação permitida , ou seja, quantas solicitações por segundo o solicitante tem permissão para realizar para o (s) recurso (s) fornecido (s).

OAuth (Open Authorization) é um protocolo padrão para acesso delegado , frequentemente usado pelas principais empresas da Internet para conceder acesso sem fornecer a senha. Como está claro, o OAuth é o protocolo que atende às preocupações mencionadas acima: Autenticação e autorização, fornecendo acesso delegado seguro aos recursos do servidor em nome do proprietário do recurso. Baseia-se no mecanismo de tokens de acesso que permite a terceiros obter acesso ao recurso gerenciado pelo servidor em nome do proprietário do recurso. Por exemplo, ServiceX deseja acessar a Conta do Google de John Smith em nome de John, assim que John tiver autorizado a delegação; O ServiceX receberá então um token baseado em tempo para acessar os detalhes da Conta do Google, muito provavelmente apenas no acesso de leitura.

O conceito de chave de API é muito semelhante ao token OAuth descrito acima. A principal diferença consiste na ausência de delegação: o Usuário solicita diretamente a Chave ao provedor de serviço para sucessivas interações programáticas. O caso da chave API também é baseado no tempo: a chave, como token OAuth, está sujeita a uma concessão por tempo ou período de expiração. Como aspecto adicional, a Chave, assim como o Token, podem estar sujeitos à limitação de taxa por contrato de serviço, ou seja, apenas um determinado número de solicitações por segundo pode ser atendido.

Para recapitular, na realidade não há diferença real entre os mecanismos tradicionais de autenticação e autorização e as versões baseadas em chave / token. O paradigma é um pouco diferente: em vez de continuar reutilizando credenciais em cada interação entre cliente e servidor, uma chave / token de suporte é usada, o que torna a experiência de interação geral mais suave e provavelmente mais segura (frequentemente, seguindo o padrão JWT , Chaves e Os tokens são assinados digitalmente pelo servidor para evitar a fabricação).

  • Autenticação e autorização direta : protocolos baseados em chave como uma variante das versões tradicionais baseadas em credenciais.
  • Autenticação e autorização delegadas : como os protocolos baseados em OAuth, que por sua vez usam Tokens, novamente como uma variante das versões baseadas em credenciais (o objetivo geral é não divulgar a senha a terceiros).

Ambas as categorias usam um fluxo de trabalho de verificação de identidade tradicional para a primeira interação com o servidor que possui o (s) recurso (s) interessado (s).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.