Eu tenho o desafio de implementar uma API para ser consumida por clientes relativamente não-técnicos - colando algum código de exemplo em seu site WordPress ou PHP nativo é provavelmente o máximo que podemos pedir. Pedindo-lhes para instalar o SSL em seus servidores não está acontecendo. Por isso, estou procurando uma maneira simples, mas segura, de autenticar clientes da API.
OAuth é a solução óbvia, mas não acho que passe no teste "simples".
Adicionar um id de cliente e um segredo hash como um parâmetro para as solicitações está mais próximo - não é difícil fazer md5($secret . $client_id) ou qualquer que seja o php.
Parece-me que se as solicitações dos clientes pudessem usar a mesma abordagem das chaves públicas SSH (o cliente nos fornece uma chave de seus servidores, deve haver alguma mágica existente para fazer com que todas as transações subseqüentes funcionem como regulares Solicitações de API HTTP.
Eu ainda estou trabalhando nisso (obviamente :-), então se eu estou sendo um idiota, seria bom saber o porquê.
Obrigado!
Se você estiver hospedando o serviço, poderá configurar o SSL ao seu lado. Existem várias opções para autenticar os clientes.
Algo semelhante a chaves públicas SSH é a autenticação de certificado de cliente SSL, também conhecida como 2 vias SSL.
É um tópico bastante grande, sua API é puramente baseada na web? Por que o SSL é muito difícil? Se você quiser comunicações confiáveis de clientes automatizados e garantir o não-repúdio, você precisará de SSL. Se sua API for acessada a partir de uma sessão de usuário, você poderá implementar a autenticação de 2 fatores. Usando algo como os tokens RSA ou até mesmo o google authenticator, se eles tiverem smartphones.
Da maneira mais simples, você pode ativar a autenticação HTTP básica ao seu lado. Desde que você tenha habilitado HTTPS em seu servidor e tenha certeza de que os clientes foram configurados com https:// URIs ( evite depender de redirecionamentos automáticos , especialmente com o HTTP Basic na verdade). Basta dar a cada cliente registrado um nome de usuário e uma senha.
A maioria dos clientes deve suportar essa forma de autenticação. Se o seu cliente for um servidor PHP, deverá definir os parâmetros CURLOPT_USERPWD .
Também é bastante comum usar uma chave de API (com base em algum UUID, por exemplo) como um parâmetro de consulta para algumas APIs. Quão conveniente isso pode depender do seu lado do código. No geral, é bastante equivalente ao nome de usuário / senha básicos em termos de segurança (exceto pelo fato de que você pode ter que mapear a chave para um nome de usuário).
Se você quiser usar autenticação de chave pública, use certificados de cliente SSL / TLS. Isso está mais envolvido. Você pode ter que criar sua própria CA para isso (isso pode ser feito de tal forma que a geração de chaves seja feita no navegador do usuário, mas isso ainda pode ser inconveniente). 1
A desvantagem é que os usuários podem ter que converter certificados de um formato para outro para serem usados.
De qualquer forma, se SSL é usado do seu lado e você espera que eles colem algum código PHP / Curl, eles ainda podem ter que fazer um pouco de configuração. Pelo menos, CURLOPT_SSL_VERIFYPEER deve ser TRUE , CURLOPT_SSL_VERIFYHOST deve ser 2 (padrão) e CURLOPT_CAPATH deve apontar para um diretório contendo seus certificados CA confiáveis. Onde isso pode depender do seu host.
1 Também é possível transformar uma chave SSH RSA em um certificado X.509 auto-assinado, mas isso é bastante técnico (e também exigiria algum trabalho do seu lado). Outros mecanismos de autenticação de chave pública (possivelmente baseados em chaves SSH) em cima do HTTP estariam à sua disposição para criar, o que geralmente é uma má idéia (difícil de se acertar por conta própria). Certamente não vale a pena o esforço, já que o HTTPS com autenticação de cliente forneceria algo comprovado e já suportado por bibliotecas existentes.
Eu acho que o que você pode fazer é usar o Diffie Hellman para criar um segredo compartilhado baseado em pares de chaves públicas / privadas. Eu usei uma abordagem semelhante; Eu acho que se você está tentando controlar a autorização para sua API de várias fontes, essa abordagem pode funcionar bem.
Por favor, veja este link