Integration Service
latest
false
Importante :
Este conteúdo foi traduzido com auxílio de tradução automática. A tradução dos pacotes de Conetores disponíveis no Integration Service é efetuada automaticamente.
Guia do usuário do Integration Service
Automation CloudAutomation Cloud Public Sector
Last updated 19 de jul de 2024

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:


docs image

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.
    docs image

  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.
    docs image

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.
CampoDescription
ID do ClienteIdentificador do aplicativo gerado pelo provedor.
Segredo do clienteChave secreta do aplicativo gerada pelo provedor.
URL de autorizaçãoA URL que redireciona o usuário para concluir o processo de autenticação. Retorna um código de autorização.
URL do tokenURL que a UiPath usa para trocar o código de autorização por um token.

Additional Fields

CampoDescription
EscopoAdicione os escopos necessários para um conector com um espaço separando cada escopo (ou seja, read write openid).
URL de atualização do tokenURL 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 tokenURL necessário para revogar o token de acesso.
Intervalo de atualizaçãoPor quanto tempo o token de acesso é válido. O valor padrão é de 3600 segundos ou 60 minutos.
Nome da ConexãoO nome da conexão no UiPath quando a autenticação é concluída.
Cabeçalho básicoIndica 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® 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 do token de atualização, regenera automaticamente os tokens de acesso em segundo plano, conforme a necessidade. 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}'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.
CampoDescription
ID do ClienteIdentificador do aplicativo gerado pelo provedor.
Segredo do clienteChave secreta do aplicativo gerada pelo provedor.
URL de autorizaçãoA URL que redireciona o usuário para concluir o processo de autenticação. Retorna um código de autorização.
URL do tokenURL que a UiPath usa para trocar o código de autorização por um token.

Additional Fields

CampoDescription
EscopoAdicione os escopos necessários para um conector com um espaço separando cada escopo (ou seja, read write openid).
URL de atualização do tokenURL 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 OAuth2O método usado para gerar o desafio. Pode ser S256 ou plain (recomendado: S256).
URL de revogação do tokenURL necessário para revogar o token de acesso.
Intervalo de atualizaçãoPor quanto tempo o token de acesso é válido. O valor padrão é de 3600 segundos ou 60 minutos.
Nome da ConexãoO nome da conexão no UiPath quando a autenticação é concluída.
Cabeçalho básicoIndica 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 campos 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 do token de atualização, regenera automaticamente os tokens de acesso em segundo plano, conforme a necessidade. 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}',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.
CampoDescription
ID do ClienteIdentificador do aplicativo gerado pelo provedor.
Segredo do clienteChave secreta do aplicativo gerada pelo provedor.
URL do tokenURL usado para recuperar o token de acesso.

Additional Fields

CampoDescription
EscopoAdicione os escopos necessários para um conector com um espaço separando cada escopo (ou seja, read write openid).
Intervalo de atualizaçãoPor quanto tempo o token de acesso é válido. O valor padrão é de 3600 segundos ou 60 minutos.
Nome da ConexãoO nome da conexão no UiPath quando a autenticação é concluída.
Cabeçalho básicoIndica 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® gera uma solicitação de autorização, passando pelas credenciais necessárias para gerar um token de acesso. Como as credenciais de cliente do OAuth 2.0 se destinam a aplicativos M2M, você vê apenas a página inicial de autorização da UiPath e não terá mais 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}',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

CampoDescription
UsernameO primeiro valor nos dois pontos de duas partes delineados e o valor do cabeçalho Authorization codificado em Base64.
SenhaO segundo valor nos dois pontos de duas partes delineados e o valor do cabeçalho Authorization codificado em Base64.
Nome da ConexãoO nome da conexão no UiPath quando a autenticação é concluída.

Como funciona

Quando fornecido com 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 é passado 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)'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

CampoDescription
Chave de APIA 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ãoO 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}'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

CampoDescription
Token de acesso pessoalO 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ãoO 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}'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'curl --request GET \
  --url https://{baseUrl}/{resource} \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json'

Esta página foi útil?

Obtenha a ajuda que você precisa
Aprendendo RPA - Cursos de automação
Fórum da comunidade da Uipath
Uipath Logo White
Confiança e segurança
© 2005-2024 UiPath. Todos os direitos reservados.