Onde colocar uma chave de API: um cabeçalho HTTP personalizado VS o cabeçalho de Autorização com um esquema personalizado

Estou projetando uma API REST usando autorização / autenticação por meio de uma chave de API.

Tentei descobrir qual é o melhor lugar para isso e descobri que muitas pessoas sugerem o uso de um cabeçalho HTTP personalizado, como ProjectName-Api-Key, por exemplo:

ProjectName-Api-Key: abcde

mas também é possível e ideologicamente correto usar o Authorizationcabeçalho com um esquema personalizado, por exemplo:

Authorization: ApiKey abcde

Por outro lado, considerei que um esquema de Autorização personalizado pode ser inesperado e não suportado por alguns clientes e leva ao código personalizado de qualquer maneira, portanto, é melhor usar um cabeçalho personalizado, pois os clientes não têm expectativas sobre isso.

De que maneira você prefere enviar uma chave de API?

— RomanG
fonte

Os projetos sob minha orientação usam Authorization: Bearer <token>cabeçalho e nunca houve um único problema com isso. Os tokens são JWTs .

— 21717 Andy

@DavidPacker Pelo que entendi, o Beareresquema é usado exclusivamente com oAuth2. A aplicação separada do oAuth soa como mau uso. Por que é correto usar esse esquema se não há oAuth? A propósito, tive problemas com a escolha de um tipo de autorização para minha API. A API estará disponível apenas para um serviço confiável; portanto, investiguei o fluxo de credenciais do cliente oAuth2 e não encontrei nenhum benefício em comparação com o ApiKey no meu caso.

— romang

@DavidPacker Entendi que a autorização do ApiKey poderia ser considerada uma implementação válida do oAuth se ApiKeyfosse renomeada e interpretada como Access Tokenconcedida ao cliente sem um prazo de validade. Esse é um tipo de aspecto filosófico, decidi não trazer definições complexas se meu caso puder ser descrito em termos simples e decidi chamá-lo apenas de "ApiKey". Se o seu protocolo implementar oAuth Standart, posso concordar em usá- Bearerlo, mas não, acho que esse esquema não pode ser aplicado.

— romang

Você está se limitando demais. O consumidor da API não se importava se você implementou o OAuth ou não. Eles se preocupam com a segurança do token, esse trabalho de emissão de token e que eles podem ser devidamente autenticados. Eles recomendam o uso do Bearer diretamente na documentação do JWT . O JWT se encaixa perfeitamente no esquema do Portador e eu não poderia recomendar mais os JWTs. Eles são perfeitos para aplicativos REST porque você pode autenticar um usuário mesmo sem acessar o banco de dados - a menos que precise do recurso de revogação de token.

— 219 Andy

(drive by) ... lembre-se de saber que as chaves da API são segredos compartilhados normalmente compartilhados entre uma terceira parte confiável configurada e um autenticador, para não comunicar identidade ou autorização. Em outras palavras, eles destinam-se apenas a iniciar um handshake de segurança, não a representar um resultado de autenticação. A chave api comunica sua autoridade para se identificar contra o autenticador confiável do sistema. Usando a chave como um token para controlar o acesso recurso seguro é ruim juju

— K. Alan Bates

Se você usa Autorização, seja consistente

Alguns argumentam que o seguinte é desnecessário ( e não muito tempo atrás, eu teria concordado com eles ), mas hoje em dia, se usarmos o Authorizationcabeçalho, devemos informar o tipo do token, porque as chaves da API não são auto-descritivas por si só ¹ .

Por que eu acho que é necessário e por que eu acho que é importante? Porque hoje em dia o suporte a diferentes protocolos de autenticação / autorização se tornou um item obrigatório. Se planejamos usar o Authorizationcabeçalho para todos esses protocolos, precisamos tornar nosso serviço de autenticação consistente. A maneira de comunicar que tipo de token enviamos e que protocolo de autorização deve ser aplicado também devem estar no cabeçalho.

Authorization: Basic xxxx
Authorization: Digest xxxx
Authorization: Bearer xxxx
Authorization: ApiKey-v1 xxxx
Authorization: ApiKey-v2 xxxx

Eu não me importava com isso, mas depois de trabalhar com aplicativos clientes de aplicativos cujas atualizações não eram garantidas (principalmente celulares e sensores), comecei a fazê-lo. Comecei a ser mais cauteloso na maneira de implementar a segurança para poder expandi-la sem mexer com os clientes e sem muita dor no lado do servidor.

Preocupações

Os problemas que enfrentei ao implementar meus próprios esquemas foram semelhantes aos comentados.

Por outro lado, considerei que um esquema de autorização personalizado pode ser inesperado e não suportado por alguns clientes e leva ao código personalizado de qualquer maneira

Digamos clientes , digamos bibliotecas, estruturas, proxies reversos .

Vantagens

Uma vantagem importante é o cache. Caches compartilhados não armazenam em cache o cabeçalho (e isso é bom, é claro), a menos que você diga o contrário.

Então, autorização ou cabeçalho personalizado?

Para minha experiência, implementar meu próprio Authorizationesquema me levou a mesma quantidade de trabalho (ou mais) do que implementar cabeçalhos de autorização personalizados, com a pequena diferença de ter mais liberdade de design e mais controle sobre o cache quando usei cabeçalhos personalizados. O motivo é bastante estúpido, na maioria das vezes em que eu tenho o Cache-controlconjunto no-cacheou no-store, permitindo que eu faça as chamadas para o servidor mais determinísticas (isso é importante quando se trata de rastreamento e teste), independentemente da topologia da rede.

^{1: Acho esta resposta muito clara em relação às chaves de API}

— Laiv
fonte

O uso de X-está obsoleto em 2012: stackoverflow.com/a/3561399/923720

— Darkhogg

ops! Eu não sabia Editado e corrigido.

— LAIV

Antes desta pergunta, pensei que quase todo mundo colocasse a chave da API na URL, mas usava o HTTPS para ocultá-la. É bom ver algumas alternativas. Por exemplo, com conteúdo permite Autorização ou pamameter consulta: contentful.com/developers/docs/references/content-delivery-api/...

— user949300

@ user949300 ... usar um segredo compartilhado criptografado (por exemplo, chave api em uri sobre ssl) é obviamente mais seguro do que nada, mas é facilmente falsificado se for interceptado e não fornece granularidade sobre identidades. Nunca usei api_keys para nada além de comunicação máquina a máquina, onde estou correspondendo o segredo compartilhado entre as partes confiantes e as identidades da máquina na lista de permissões autorizadas a agir com esse segredo compartilhado. Depois de feita a conexão máquina a máquina, o operador humano se autentica usando outros meios.

— K. Alan Bates

@K. Alan Bates A maioria das minhas interações com a API foi relativa a coisas "sem importância", como camadas gratuitas de geocodificação, boletins meteorológicos e coisas semelhantes, onde a chave da API é mais para limitar a taxa do que segredos sérios do usuário. Portanto, quanto ao OP, depende de qual nível de segurança é necessário.

— user949300