"Todo mundo sente necessidade de escrever seu próprio protocolo de autenticação", diz George Reese, referindo-se a algo que afirma ter aprendido na programação de APIs para provedores de serviços na nuvem. Em um post, Reese, autor da O'Reilly e especialista em cloud computing, propõe um conjunto de padrões de autenticação REST.
O autor defende que cada API requer um diferente mecanismo de autenticação:
Estou cansado de gastar neurônios descobrindo se a empresa "A" requer a assinatura de uma pesquisa antes ou depois de codificar os parâmetros da URL. Estou cheio com fornecedores que insistem em usar sistemas de autenticação interativos para autenticar chamadas de APIs.
Reese resume regras para a definição dos esquemas de autenticação de APIs REST e diz: Ele diz que:
1. Todas as chamadas REST devem ser executadas sobre HTTPS, com um certificado assinado por uma autoridade certificadora confiável. Todos os clientes devem validar o certificado antes de interagir com o servidor.
Através do uso de certificados assinados por uma autoridade segura, o SSL também protege contra um ataque do tipo "homem no meio" que consiste no agente se inserir entre o cliente e o servidor e ouvir o tráfego "criptografado". Se o certificado SSL do servidor não estiver sendo validado no servidor, não se sabe quem esta recebendo as requisições REST.
2. Toda chamada REST deve ocorrer através de chaves de API dedicadas, consistindo de um componente de identificação e uma segredo compartilhado e privado. Os sistemas devem permitir a um consumidor ter múltiplas chaves de API ativas, e desativar facilmente alguma chave em particular.
Um sistema que está fazendo uma chamada REST não é um usuário humano. [...] O REST autentica um programa, não uma pessoa. Isso permite uma autenticação mais forte do que esquemas interativos de usuário/senha. Além disso, cada servidor REST deve suportar múltiplas chaves de APIs para cada consumidor. Isso simplifica o isolamento de potenciais problemas e o seu tratamento quando ocorrerem. [...] Quando uma aplicação for comprometida, precisa-se de uma saída elegante para a troca de chaves de APIs.
3. Todas as chamadas REST devem ser autenticadas, assinando-se os parâmetros da pesquisa, que devem ser ordenados, em caixa baixa e em ordem alfabética, e usando as credenciais privadas como assinatura simbólica. A assinatura deve ocorrer antes da codificação da URL da query string.
Em outras palavras, se não for passado o componente secreto compartilhado da chave da API como parte da chamada, e em vez disso, ele for usado para assinar a chamada, a chamada se parecerá com isso:
GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789
A string sendo assinada é "/object?apikey=Qwerty2010×tamp=1261496500" e a assinatura é o hash HMAC-SHA256 da string usando o componente privado da chave da API.
George Reese admite que, na maioria das soluções de APIs RESTlike e RESTFul, a autenticação é deixada em segundo plano. Entretanto, na conclusão do seu artigo, recomenda os leitores a "seguir o exemplo de outras pessoas e não criar o próprio esquema de autenticação".
O post original pode ser encontrado nos blogs da comunidade O'Reilly.