Opções de autenticação
Antes de usar qualquer conector nos Aplicativos Lógicos do Azure, no Power Automate ou no Power Apps, o usuário precisa criar uma conexão autenticando-se no serviço de rede. Ao criar um conector personalizado, você pode definir como a pessoa que usará o conector fará a autenticação. Você pode selecionar o tipo de autenticação na guia Segurança no assistente de conector online. As informações adicionais que você precisará fornecer dependerão do esquema de autenticação selecionado.
Sem autenticação
Quando a opção Sem autenticação é selecionada, nenhuma informação adicional é necessária. O usuário não precisará de autenticação para criar uma conexão com o conector personalizado, e qualquer usuário anônimo poderá usar o conector. Essa opção é usada apenas quando a API permite o uso anônimo.
Autenticação básica
O tipo mais simples de autenticação é a Autenticação básica, em que o usuário fornecerá o nome de usuário e a senha para criar a conexão.
Os valores inseridos na coluna Rótulo do parâmetro não são o nome de usuário ou a senha reais; são rótulos para esses campos que o usuário verá ao criar a conexão.
No exemplo anterior, o usuário será solicitado a inserir Usuário e Senha para criar uma conexão. Você deve fazer a correspondência entre os rótulos e os nomes que são usados pela API para esclarecer a alguém que está criando uma conexão quais valores usar com essa conexão.
Qualquer conexão de serviço que usa a Autenticação básica deve usar o protocolo HTTPS seguro para evitar o envio de credenciais não criptografadas pela rede.
Autenticação de Chave de API
Chave de API é um esquema de autenticação popular usado por serviços Web. Por exemplo, o Microsoft Azure Functions inclui parâmetros de código como parte do modelo padrão.
Defina os seguintes valores:
Rótulo do parâmetro – o rótulo do prompt do usuário quando uma nova conexão é criada.
Nome do parâmetro – o nome do parâmetro que conterá o valor da chave durante cada solicitação de serviço.
Localização do parâmetro: oferece aos criadores a opção de enviar a chave de API no cabeçalho da solicitação ou na cadeia de consulta ao chamar o serviço subjacente.
No exemplo anterior, o usuário que estiver criando uma nova conexão verá o seguinte prompt.
O valor fornecido será enviado ao serviço subjacente como um cabeçalho de solicitação X-API-Key personalizado.
O modelo padrão do Azure Functions pode usar código como o nome do parâmetro e enviá-lo como parte da consulta, definindo o local do parâmetro como Consulta para que a URL do serviço seja semelhante a:
https://functionurl.azurewebsites.net?code=user-supplied-code/
De maneira semelhante à Autenticação básica, recomendamos que você use o esquema de autenticação Chave de API apenas com o protocolo HTTPS para evitar o envio de chaves não criptografadas.
Autenticação OAuth 2.0
O esquema de autenticação OAuth 2.0 está disponível apenas para conectores online. Além de fornecer suporte para Generic OAuth 2.0, a plataforma fornece implementações para serviços específicos, incluindo o Microsoft Entra ID, GitHub, conta Microsoft e muito mais. Quando selecionados, os modelos de provedor de identidade predefinidos preenchem muitos dos campos exigidos pelo OAuth 2.0, com valores específicos do provedor que reduzem o que você precisa fornecer.
As informações adicionais que serão coletadas dependerão do provedor de identidade. O provedor de OAuth 2.0 Genérico requer os parâmetros a seguir.
Parâmetro | Descrição |
---|---|
ID do Cliente | Identificador de aplicativo OAuth no sistema de destino, inserido manualmente ou gerado pelo provedor quando o aplicativo é registrado. |
Segredo do cliente | Segredo associado ao aplicativo OAuth, gerado pelo provedor. A maioria dos provedores também pode revogar segredos existentes e emitir novos. |
URL de autorização | A URL usada para realizar a entrada do usuário e autorizar o aplicativo, por exemplo: https://www.facebook.com/v9.0/dialog/oauth ou https://login.salesforce.com/services/oauth2/authorize . |
URL do token | A URL usada para buscar um token depois que o aplicativo é autorizado pelo usuário, por exemplo: https://graph.facebook.com/v9.0/oauth/access_token ou https://mycompany.salesforce.com/mycompany.salesforce.com . |
Atualizar URL | A URL usada para buscar um novo token usando um token de atualização após o original ter expirado. Essa URL geralmente é a mesma que a URL do token para a maioria dos serviços. |
Escopo | Cadeia de caracteres que representa as permissões que você busca do usuário. Deixe esse parâmetro em branco ou consulte a documentação do provedor para especificar o escopo de permissão que seu aplicativo requer. |
Registre o conector com o provedor de identidade como um aplicativo cliente; os detalhes de registro específicos dependem do provedor e são documentados pelo provedor de identidade. Por exemplo, para autenticar usando o Facebook, um criador criaria um aplicativo do Facebook usando suas ferramentas de desenvolvimento. Como os parâmetros ID do Cliente e Segredo do cliente fazem parte das especificações do OAuth 2.0, eles são fornecidos por todos os provedores de identidade OAuth 2.0 como parte do registro do aplicativo. Um valor que precisa ser incluído no registro do aplicativo é URL de Redirecionamento. Inicialmente, esse valor está vazio na configuração do conector, mas torna-se disponível quando a configuração é salva. Em seguida, ele pode ser copiado e salvo com o registro do conector com o provedor de identidade.
A maioria dos provedores específicos exige apenas a ID do cliente, o segredo do cliente e o escopo opcional, porque todas as URLs são predefinidas para um serviço específico.
Depois que o conector for publicado e disponibilizado para os usuários, eles serão solicitados a inserir suas credenciais para entrar no serviço durante o processo de criação da conexão. Essas credenciais serão usadas pelo aplicativo para obter um token de autorização. Para cada solicitação, esse token de autorização será enviado a seu serviço por meio do cabeçalho de autorização padrão.
O token de autorização é de curta duração, e o tempo de execução do conector usará o processo de atualização para renovação, de forma que os usuários do conector não sejam envolvidos no processo de atualização.
Autenticação do Windows
A opção de autenticação do Windows está disponível apenas para conexões que usam o gateway de dados no local, quando a caixa de seleção Conectar-se por meio do gateway de dados local é definida na guia Geral. Nenhuma informação adicional é necessária para o esquema de autenticação do Windows.
Quando uma nova conexão for criada, o usuário precisará fornecer credenciais do Windows para o serviço e selecionar um dos gateways locais instalados.
A especificação de OpenAPI que é usada pela plataforma inclui definições de Chave de API e Autenticação básica. Você também pode modificá-las diretamente online usando o editor Swagger. Outros esquemas de autenticação armazenam informações de autenticação separadamente como propriedades estendidas do conector. Embora essas informações não estejam disponíveis para edição direta edição de código-fonte online, você pode modificá-las usando a ferramenta paconn. A CLI (Interface de Linha de Comando) permite a criação de scripts do processo de implantação de conector em que a implantação automatizada é necessária.
Os conectores personalizados dão suporte a vários esquemas de autenticação para acomodar os requisitos a fim de permitir o acesso a serviços de API REST seguros. Quando os serviços de API são implantados e protegidos em um ambiente do Azure AD, a infraestrutura do conector oferece outros benefícios. Você aprenderá mais sobre as especificações do Azure AD na próxima unidade.