A maioria das APIs que consumimos como desenvolvedor requer algum tipo de autenticação. Normalmente, o provedor e o consumidor concordam com um par de chaves: chave de acesso e chave secreta (você deve evitar as palavras chaves “públicas” e “privadas”, pois podem ser interpretadas como termos igualmente nomeados do mundo da criptografia, não apropriado para este caso).
Essa prática é adequada, desde que as chaves secretas sejam armazenadas com segurança e transmitidas de um lado para o outro. Ter chaves separadas para desenvolvedores e sistemas ativos é um bom começo, assim como ter toda a comunicação via SSL. Mas se um lado está usando uma biblioteca com uma implementação SSL falha, então um intermediário pode ser capaz de extrair a chave de acesso e a chave secreta. Sem mencionar que algumas empresas oferecem acesso às suas APIs por meio de uma conexão HTTP simples. Que pena.
Você, como provedor de API, também tem a opção de concordar com o chamador em um algoritmo para resumir uma mensagem, que seria usada pela outra parte para autenticar a origem. O problema é que concordar com uma mensagem aleatória nem sempre é fácil ou seguro o suficiente, pois a mensagem em si deve ser conhecida por ambas as partes.
Uma boa solução para esse caso de uso é usar a senha de uso único baseada em tempo ou TOTP, abreviadamente. Você deve saber disso como o padrão por trás do Google Authenticator . A vantagem é que, como ambos os lados conhecem o segredo, podem gerar um TOTP e obter os mesmos resultados.
Para meu projeto favorito, decidi delegar a autenticação de aplicativos externos a um módulo separado. Nesse caso, eu apenas chamo um endpoint REST enviando a chave de acesso e TOTP, concedendo / recusando o acesso com base no código de resposta que recebi do meu serviço de autenticação . Mas também pode ser implementado como um ServletFilter
, RESTEasyPreProcessInterceptor
ou similares.
Os arquivos-chave para esta implementação podem ser encontrados no app-info
módulo e no utils
módulo , especialmente estes arquivos:
- Implementação de TOTP , com base na RFC, mas com alguns métodos extras.
- Testes de unidade , para se certificar de que nossa implementação está em conformidade com o RFC
- AppService , que usa o
accessKey
para recuperar um aplicativo do armazenamento de dados e usa osecretKey
para gerar o TOTP. Se for uma correspondência, envie um200 OK
retorno para o chamador.