Configuração da autenticação

Um dos grandes colunas para criar um conector é identificar e integrar corretamente sua configuração de autenticação. Se feito corretamente, assim que o conector for publicado no catálogo do Integration Service, os usuários poderão criar conexões com ele assim como fazem com qualquer outro conector dentro do catálogo.

Todos os conectores reutilizam a estrutura de autenticação para que o fluxo completo de autenticação e o gerenciamento de conexões possam ser processados em uma abordagem unificada.

O resultado final da autenticação é que qualquer solicitação subsequente dentro desse conector usa o resultado do processo de autenticação para cada chamada de API. Por exemplo, um token do portador é enviado nos cabeçalhos em cada chamada de API:

O Connector Builder é compatível com os seguintes padrões do setor por meio de configuração simples, em vez de codificação extensiva:

• Código de autorização do OAuth 2.0
• Código de autorização do OAuth 2.0 com PKCE
• Credenciais do cliente OAuth 2.0
• Básica
• Chave de API
• Token de acesso pessoal (PAT)
• Personalizado
• Sem autenticação

Como o Construtor de Conector está vinculado à estrutura do Integration Service, definir sua configuração de autenticação agora é uma questão de configuração, e não um processo complexo. Isso significa que o framework lida com trocas de tokens, atualizações e quaisquer outras tarefas desse tipo. O padrão do Construtor de Conector é usar o código de autorização do OAuth 2.0, já que essa é a abordagem mais comum do fornecedor para lidar com a autenticação.

A página de autenticação é feita de três componentes:

1. O Tipo de autenticação, que orienta como a estrutura de autenticação reflete com validação adicional para PKCE, troca completa de tokens (para OAuth) etc. Além disso, ele também reconfigura a tabela com propriedades por baixo, para que as propriedades necessárias fiquem delineadas.
   

   

   
   
2. A tabela de propriedades pode ser modificada com parâmetros personalizados e/ou editando os existentes. Dependendo da seleção do Tipo de autenticação no menu suspenso, alguns campos podem ser obrigatórios e especificados em vermelho.
   Observação: alterar essas propriedades dentro desta tabela ou do tipo de autenticação invalida a conexão que você já pode ter criado no Connector Builder. Há apenas uma conexão durante o tempo de design e ela precisa ser configurada e testada em relação à configuração de autenticação mais recente.

   Se você atualizar suas configurações de autenticação, as conexões existentes falharão. Você deve criar uma nova conexão e atualizar seus processos para usar a nova conexão.
3. A tela Autenticação é gerada automaticamente com base na configuração que você forneceu. O que você vê durante a configuração no Connector Builder é exatamente o resultado final que os usuários do seu pacote de atividades verão.
   
   
   
   

Configuração da tabela de autenticação

Independentemente do tipo de autenticação, a tabela de propriedades carregada identifica dois itens:

1. O que o usuário vê na tela de autenticação.
2. Como a autenticação é tratada pela estrutura de autenticação.

• Cada item de linha na tabela representa uma propriedade que pode ou não ser substituída pelo usuário. Para apresentar um determinado campo na tela, ele precisa ser sinalizado como Perguntar ao usuário — Sim.
• Cada item de linha tem um Nome e um Nome de exibição. O Nome é o que o fornecedor espera para a configuração técnica, e este é de grande importância em como solicitar essa entrada do usuário na tela de autenticação.
• Cada item de linha tem um menu de ação que permite editar a propriedade com muito mais detalhes. É aqui que você pode indicar que uma determinada propriedade precisa ser enviada como um cabeçalho. Veja mais exemplos na seção Chave de API .

Tipos de autenticação

Na guia Autenticação , você configura o tipo de autenticação para o seu conector. As seguintes opções são suportadas:

• Código de autorização do OAuth 2.0
• Código de autorização do OAuth 2.0 com PKCE
• Credenciais do cliente OAuth 2.0
• Básica
• Chave de API
• Token de acesso pessoal (PAT)
• Personalizado
• Sem autenticação

Observação:

Ao configurar a autenticação, você está configurando como qualquer pessoa que use seu conector precisa ser autenticada. É você enquanto está construindo o conector, mas também pode ser outras pessoas que acabam usando sua criação.

Código de autorização do OAuth 2.0

Visão geral

O código de autorização do OAuth 2.0 é um dos protocolos de autenticação mais usados.

Campos de autenticação

Os campos de URL, como URL de autorização e URL de token, não herdam a URL base do conector e exigem a URL completa. Isso permite casos de uso em que um provedor usa uma URL base diferente para a autenticação do resto da API.

Campos obrigatórios

Observação: o ID do cliente e o segredo do cliente geralmente são gerados a partir do provedor da API. Consulte a documentação do provedor para saber como gerar esses valores para a autenticação.

Campo	Description
ID do Cliente	Identificador do aplicativo gerado pelo provedor.
Segredo do cliente	Chave secreta do aplicativo gerada pelo provedor.
URL de autorização	A URL que redireciona o usuário para concluir o processo de autenticação. Retorna um código de autorização.
URL do token	URL que a UiPath usa para trocar o código de autorização por um token.

Additional Fields

Campo	Description
Escopo	Adicione os escopos necessários para um conector com um espaço separando cada escopo (ou seja, read write openid).
URL de atualização do token	URL necessário para gerar um novo token de acesso se um token de atualização também for retornado. Frequentemente, esta é a mesma URL usada para a URL do Token.
URL de revogação do token	URL necessário para revogar o token de acesso.
Intervalo de atualização	Por quanto tempo o token de acesso é válido. O valor padrão é de 3600 segundos ou 60 minutos.
Nome da Conexão	O nome da conexão no UiPath quando a autenticação é concluída.
Cabeçalho básico	Indica se o ID e o segredo do cliente são enviados como um valor codificado em Base64 no cabeçalho Authorization . Valor booleano (True/False); o padrão é verdadeiro.

Como funciona

Depois que todos os valores de campo forem adicionados ou configurados para o conector, o UiPath® orienta você automaticamente pelas etapas necessárias para concluir o fluxo de autenticação. A UiPath é compatível com o protocolo e, se for fornecida com um URI de token de atualização, regenera automaticamente tokens de acesso em segundo plano conforme necessário. Isso mantém a conexão ativa e funcional enquanto o token de atualização subjacente for válido.

Formato de solicitação pós-autorização

Depois que a configuração inicial é concluída e uma conexão é feita, todas as solicitações feitas para esse conector têm o cabeçalho de autorização incluído automaticamente na solicitação.

curl --request GET \
  --url https://{baseUrl}/{resource} \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer {yourToken}'

Código de autorização do OAuth 2.0 com PKCE

Visão geral

O código de autenticação OAuth 2.0 com PKCE (Proof Key for Code Exchange) é um protocolo de autenticação comum aproveitado em grande parte por aplicativos de página única, aplicativos que não podem armazenar com segurança um Segredo do Cliente ou aplicativos que não podem garantir a recuperação segura de um código de autorização.

Campos de autenticação

Os campos de URL, como URL de autorização e URL de token, não herdam a URL base do conector e exigem a URL completa. Isso permite casos de uso em que um provedor usa uma URL base diferente para a autenticação do resto da API.

Campos obrigatórios

Observação: o ID do cliente e o segredo do cliente geralmente são gerados a partir do provedor da API. Consulte a documentação do provedor para saber como gerar esses valores para a autenticação.

Campo	Description
ID do Cliente	Identificador do aplicativo gerado pelo provedor.
Segredo do cliente	Chave secreta do aplicativo gerada pelo provedor.
URL de autorização	A URL que redireciona o usuário para concluir o processo de autenticação. Retorna um código de autorização.
URL do token	URL que a UiPath usa para trocar o código de autorização por um token.

Additional Fields

Campo	Description
Escopo	Adicione os escopos necessários para um conector com um espaço separando cada escopo (ou seja, read write openid).
URL de atualização do token	URL necessário para gerar um novo token de acesso se um token de atualização também for retornado. Frequentemente, esta é a mesma URL usada para a URL do Token.
Método de desafio do código PKCE do OAuth2	O método usado para gerar o desafio. Pode ser S256 ou plain (recomendado: S256).
URL de revogação do token	URL necessário para revogar o token de acesso.
Intervalo de atualização	Por quanto tempo o token de acesso é válido. O valor padrão é de 3600 segundos ou 60 minutos.
Nome da Conexão	O nome da conexão no UiPath quando a autenticação é concluída.
Cabeçalho básico	Indica se o ID e o segredo do cliente são enviados como um valor codificado em Base64 no cabeçalho Authorization . Valor booleano (True/False); o padrão é verdadeiro.

Como funciona

Depois que todos os valores de campo forem adicionados ou configurados para o conector, a UiPath® automaticamente você passará pelas etapas necessárias para concluir o fluxo de autenticação. A UiPath é compatível com o protocolo e, se for fornecida com um URI de token de atualização, regenera automaticamente tokens de acesso em segundo plano conforme necessário. Isso mantém a conexão ativa e funcional enquanto o token de atualização subjacente for válido.

A UiPath fornece a string de desafio necessária para a autorização baseada no PKCE, sendo necessário apenas o Método de Desafio de Código do PKCE do OAuth2.

Formato de solicitação pós-autorização

Depois que a configuração inicial é concluída e uma conexão é feita, todas as solicitações feitas para esse conector têm o cabeçalho de autorização incluído automaticamente na solicitação.

curl --request GET \
  --url https://{baseUrl}/{resource} \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json'
  --header 'Authorization: Bearer {yourToken}',

Credenciais do cliente OAuth 2.0

Visão geral

As credenciais de cliente do OAuth 2.0 são um método para retornar um token de acesso que concede acesso a recursos protegidos usando credenciais específicas do aplicativo, que concedem a permissão necessária. As credenciais de cliente são frequentemente usadas para aplicativos máquina a máquina (M2M) e geralmente não representam permissões de usuário.

Campos de autenticação

Campos de URL, como URL do Token, não herdam a URL base do conector e exigem a URL completa. Isso permite casos de uso em que um provedor usa uma URL base diferente para a autenticação do resto da API.

Campos obrigatórios

Observação: o ID do cliente e o segredo do cliente geralmente são gerados a partir do provedor da API. Consulte a documentação do provedor para saber como gerar esses valores para a autenticação.

Campo	Description
ID do Cliente	Identificador do aplicativo gerado pelo provedor.
Segredo do cliente	Chave secreta do aplicativo gerada pelo provedor.
URL do token	URL usado para recuperar o token de acesso.

Additional Fields

Campo	Description
Escopo	Adicione os escopos necessários para um conector com um espaço separando cada escopo (ou seja, read write openid).
Intervalo de atualização	Por quanto tempo o token de acesso é válido. O valor padrão é de 3600 segundos ou 60 minutos.
Nome da Conexão	O nome da conexão no UiPath quando a autenticação é concluída.
Cabeçalho básico	Indica se o ID e o segredo do cliente são enviados como um valor codificado em Base64 no cabeçalho Authorization . Valor booleano (True/False); o padrão é verdadeiro.

Como funciona

Depois que todos os valores de campo são adicionados ou configurados para o conector, o UiPath® gera uma solicitação de autorização, passando pelas credenciais necessárias para gerar um token de acesso. Como as credenciais de cliente OAuth 2.0 se destinam a aplicativos M2M, você só vê a página inicial de autorização da UiPath e não terá outros redirecionamentos.

Após um fluxo de autorização bem-sucedido ser detectado, a UiPath mantém a conexão enquanto as credenciais fornecidas forem válidas.

Formato de solicitação pós-autorização

Depois que a configuração inicial é concluída e uma conexão é feita, todas as solicitações feitas para esse conector têm o cabeçalho de autorização incluído automaticamente na solicitação.

curl --request GET \
  --url https://{baseUrl}/{resource} \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json'
  --header 'Authorization: Bearer {yourToken}',

Autenticação básica

Visão geral

O tipo de autenticação básica permite que você defina um nome de usuário e senha, que são codificados em Base64 e prefixados com Basic. O nome de usuário e a senha, que podem ser modificados, são usados em todas as solicitações de conector como o valor para o cabeçalho de autorização.

Campos de autenticação

Campo	Description
Username	O primeiro valor nos dois pontos de duas partes delineados e o valor do cabeçalho Authorization codificado em Base64.
Senha	O segundo valor nos dois pontos de duas partes delineados e o valor do cabeçalho Authorization codificado em Base64.
Nome da Conexão	O nome da conexão no UiPath quando a autenticação é concluída.

Como funciona

Quando recebe os valores de nome de usuário e senha, o UiPath® combina e separa os valores por dois pontos, os codifica em Base64 e prefixa Basic para gerar um valor de cabeçalho Authorization (por exemplo, Authorization: Basic base64(username:password)). Esse valor do cabeçalho é transmitido em cada solicitação como um meio de autenticação.

Formato de solicitação pós-autorização

Depois que a configuração inicial é concluída e uma conexão é feita, todas as solicitações feitas para esse conector têm o cabeçalho de autorização incluído automaticamente na solicitação.

curl --request GET \
  --url https://{baseUrl}/{resource} \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json'
  --header 'Authorization: Basic base64(username:password)'

Chave de API

Visão geral

Alguns provedores oferecem uma chave de API como uma forma de autenticação para acessar seus recursos de API. No Construtor de Conector, esse tipo de autenticação resulta no uso de um cabeçalho 'X-Acess-Token: <provider_api_key>' , que é passado em solicitações do conector.

Campos de autenticação

Campo	Description
Chave de API	A chave de API gerada a partir do provedor de API a ser usada como o valor para o cabeçalho X-Access-Token em todas as solicitações do conector.
Nome da conexão	O nome da conexão no UiPath quando a autenticação for concluída

Como funciona

Ao usar o valor da chave de API gerada pelo provedor para o parâmetro Chave de API em Configurações - Autenticação, cada solicitação feita para esse conector inclui um cabeçalho X-Access-Token com a chave de API fornecida como o valor do cabeçalho.

Formato de solicitação pós-autorização

Após a configuração inicial ser concluída e uma conexão ser feita, todas as solicitações feitas para esse conector têm o cabeçalho X-Access-Token incluído automaticamente na solicitação.

curl --request GET \
  --url https://{baseUrl}/{resource} \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json'
  --header 'X-Access-Token: {yourtoken}'

Token de acesso pessoal

Visão geral

Alguns provedores fornecem tokens de acesso que não expiram e usam o padrão de cabeçalho Authorization: {access_token} para autenticar solicitações. O método de autenticação PAT permite que você forneça o token de acesso necessário e aplica os cabeçalhos listados anteriormente, mas não mantém o token de acesso se ele expirar em qualquer ponto.

Campos de autenticação

Campo	Description
Token de acesso pessoal	O token de acesso gerado pelo provedor a ser usado como um valor no campo do cabeçalho Authorization em todas as solicitações do conector. O padrão do campo é prefixar o token com Bearer para acomodar o padrão de autenticação de portador comum.
Nome da Conexão	O nome da conexão no UiPath quando a autenticação é concluída.

Como funciona

Ao usar o valor da chave de API gerada pelo provedor para o parâmetro Personal Access Token em Configurações - Autenticação, cada solicitação feita para esse conector inclui um cabeçalho X-Access-Token com o token de acesso pessoal fornecido como o valor do cabeçalho.

Formato de solicitação pós-autorização

Após a configuração inicial ser concluída e uma conexão ser feita, todas as solicitações feitas para esse conector têm o cabeçalho Authorization incluído automaticamente na solicitação.

curl --request GET \
  --url https://{baseUrl}/{resource} \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json'
  --header 'Authorization: {personal_access_token}'

Personalizado

Visão geral

A autenticação personalizada deve ser usada quando a configuração do fornecedor não segue nenhum dos padrões, mas requer que os detalhes de autenticação sejam trocados e enviados em todas as solicitações.

Campos de autenticação

Os campos de autenticação personalizados vêm com um parâmetro Authorization como um campo de exemplo, mas podem ser personalizados para corresponder aos padrões de autenticação do provedor da API.

Quaisquer parâmetros adicionados à autenticação da Autenticação personalizada se aplicam às solicitações do conector.

Observação: por enquanto, a Autenticação personalizada não permite que você crie um fluxo de autenticação personalizado. Isso permite personalizar os parâmetros de autenticação padrão aplicados às solicitações dentro do conector.

Como funciona

Os parâmetros adicionados à seção de autenticação são incluídos automaticamente em qualquer solicitação de conector.

Sem autenticação

A opção Sem autenticação fornece uma seleção rápida da listagem e exclui todas as propriedades da tabela de configuração de autenticação.

Como usá-lo

Use essa opção se o aplicativo do fornecedor ao qual você está se conectando estiver disponível sem a necessidade de fazer login. Isso pode ser um serviço público online ou uma API que está exposta internamente dentro da empresa. Não é necessário que cabeçalhos sejam enviados em qualquer solicitação que identifique quem está fazendo a chamada de API.

Resultado ao enviar uma solicitação

curl --request GET \
  --url https://{baseUrl}/{resource} \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json'