Provedor de segurança de chave de API no Jitterbit App Builder
O provedor de segurança de chave de API permite que os administradores protejam APIs REST do App Builder usando "chaves de API ". Uma chave de API é um código gerado pelo App Builder. O consumidor passa a chave de API para o App Builder ao fazer solicitações de API REST. Como cada chave de API é associada a um usuário individual, isso fornece autenticação e autorização.
Chaves de API vs. nome de usuário e senhas
Uma chave de API é semelhante a um nome de usuário e senha, pois é um segredo compartilhado entre o cliente e o servidor. Chaves de API compartilham várias fraquezas com esquemas de autenticação de nome de usuário e senha, como a Autenticação Básica HTTP:
- Chaves de API podem vazar.
- A distribuição de chaves de API pode ser difícil de gerenciar.
No entanto, as chaves de API têm vantagens sobre nomes de usuário e senhas:
- Chaves de API têm maior entropia do que combinações de nome de usuário/senha.
- As chaves de API podem sobreviver a uma redefinição de senha.
- As chaves de API podem ser facilmente revogadas.
- As chaves de API podem ser rotacionadas.
- Chaves de API são mais rápidas. Senhas devem ser hash, o que é deliberadamente lento.
Usos da chave API
Apesar das fraquezas das chaves de API, elas ainda podem ser apropriadas para certos cenários, incluindo:
- Contas de nível de serviço
- Comunicação de aplicação para aplicação
- Comunicação servidor-servidor
- Acesso somente leitura
- Informações não sensíveis
Material da chave da API
As chaves de API do App Builder consistem em um número criptograficamente aleatório de 128 bits. As chaves são codificadas em base64url.
A seguir está um exemplo de uma chave de API:
DLOo9sPS5slJEMHpXBFt3g
Configuração
Parâmetros
O provedor de segurança da chave de API define os seguintes parâmetros:
| Parâmetro | Valor padrão | Descrição |
|---|---|---|
| AllowApiKeyInQueryString | False | Indica se o provedor de segurança deve aceitar chaves de API passadas na string de consultar. Por padrão, o provedor de segurança só permitirá que chaves de API sejam passadas nos cabeçalhos de solicitação HTTP. Veja abaixo para mais informações. |
| AllowUnsafeHttpConnections | False | Indica se o provedor de segurança deve aceitar chaves de API enviadas por meio de uma solicitação HTTP insegura. Por padrão, o provedor de segurança só permitirá que chaves de API sejam passadas por uma conexão HTTPS segura. Veja abaixo para mais informações. |
Cabeçalho HTTP vs. sequência de consultar
Normalmente, o cliente passará a chave da API por meio de um cabeçalho personalizado. O cabeçalho deve ser nomeado X- API-Key. Isso limita o risco de exposição. Por exemplo, em contraste com os parâmetros de sequência de consultar, os cabeçalhos HTTP raramente são registrados no disco.
O exemplo a seguir demonstra como passar a chave da API como um cabeçalho HTTP:
GET /App Builder/rest/v1/sales/customers HTTP/1.1
Host: example.com:443
Accept: application/json
X-API-Key: DLOo9sPS5slJEMHpXBFt3g
Alguns clientes podem não ter acesso aos cabeçalhos de solicitação HTTP. Se esse for o caso, e nenhuma outra solução alternativa estiver disponível, os administradores de segurança podem habilitar a opção AllowApiKeyInQueryString. Isso forçará o App Builder a aceitar a chave da API como um parâmetro de sequência de caracteres de consultar. O parâmetro de sequência de caracteres de consultar deve ser nomeado apiKey.
O exemplo a seguir demonstra como passar a chave de API como um parâmetro de string de consultar:
GET /App Builder/rest/v1/sales/customers?apiKey=DLOo9sPS5slJEMHpXBFt3g HTTP/1.1
HOST: example.com:443
Accept: application/json
Observe que há um potencial conflito aqui. Ao consultar a REST API, os parâmetros de string de consultar normalmente são mapeados para nomes de campos de recursos. Se as chaves de API puderem ser passadas como um parâmetro de string de consultar, os recursos não poderão ter um campo chamado "apiKey".
HTTPS vs. HTTP
Para evitar ataques do tipo man-in-the-middle, as chaves de API devem ser passadas por uma conexão HTTPS segura. O App Builder impõe isso ignorando as chaves de API passadas por HTTP.
No entanto, em alguns ambientes, a conexão HTTPS pode ser encerrada antes do servidor web. Nesse cenário, os administradores de segurança podem habilitar a opção AllowUnsafeHttpConnections para forçar o App Builder a aceitar chaves de API enviadas por conexões HTTP inseguras.