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

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?

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/

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).