- Introdução
- Notificações
- Licenciamento
- Solução de problemas
- Construtor de Conector
- Act! 365
- Active Directory - Visualização
- ActiveCampaign
- Adobe Acrobat Sign
- Adobe PDF Services
- Amazon Bedrock
- Amazon Connect
- Amazon Polly
- Amazon SES
- Amazon Transcribe
- Amazon Web Services
- Anthropic Claude
- Asana
- AWeber
- Azure AI Document Intelligence
- Azure Maps
- BambooHR
- Box
- Brevo
- Calendly
- Campaign Monitor
- Cisco Webex Teams
- Citrix Hypervisor
- Citrix ShareFile
- Clearbit
- Confluence Cloud
- Constant Contact
- Coupa
- Customer.io
- Datadog
- Deputy
- DocuSign
- Gota
- Dropbox
- Egnyte
- Eventbrite
- Exchange Server - Pré-visualização
- Taxas de câmbio
- Expensify
- Facebook
- Freshbooks
- Freshdesk
- Freshservice
- GetResponse
- GitHub
- Gmail
- Google Cloud Platform
- Documentos Google
- Google Drive
- Google Maps
- Planilhas Google
- Google Speech-to-Text
- Google Tasks - Visualização
- Text-to-Speach do Google
- Google Vertex
- Google Vision - Pré-visualização
- Google Workspace - Visualização
- GoToWebinar
- Greenhouse
- Hootsuite
- HTTP Webhook - Visualização
- Hubspot CRM
- HubSpot Marketing
- HyperV - Pré-visualização
- iContact
- Insightly CRM
- Intercom
- Jira
- Keap
- Klaviyo
- LinkedIn
- Mailchimp
- MailerLite
- Mailgun
- Mailjet
- Marketo
- Microsoft 365
- Microsoft Azure
- Microsoft Azure Active Directory
- Microsoft Azure OpenAI
- Microsoft Dynamics 365 CRM
- Microsoft OneDrive & SharePoint
- Microsoft Outlook 365
- Microsoft Sentiment
- Microsoft Teams
- Microsoft Translator
- Microsoft Vision
- Miro
- NetIQ eDirectory
- OKTA
- OpenAI
- Oracle Eloqua
- Oracle NetSuite
- PagerDuty
- Paypal
- PDFMonkey
- Pinecone
- Pipedrive
- QuickBooksOnline
- Quip
- Salesforce
- Salesforce Marketing Cloud
- SAP BAPI - Pré-visualização
- SAP Cloud for Customer
- SAP Concur
- SendGrid
- ServiceNow
- Shopify
- Slack
- SmartRecruiters
- Smartsheet
- Snowflake
- Stripe
- Sugar Enterprise
- Sugar Professional
- Sugar Sell
- Sugar Serve
- System Center - Pré-visualização
- TangoCard
- Todoist
- Trello
- Twilio
- VMware ESXi vSphere
- watsonx.ai
- WhatsApp Business
- UiPath Marketplace
- Funcional
- Workday
- X (anteriormente Twitter)
- Xero
- YouTube
- Zendesk
- Zoho Campaigns
- Zoho Desk
- Zoho Mail
- ZoomInfo
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:
-
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.
- 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.
- 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.
Independentemente do tipo de autenticação, a tabela de propriedades carregada identifica dois itens:
- O que o usuário vê na tela de autenticação.
- 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 .
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
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.
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
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}'
curl --request GET \
--url https://{baseUrl}/{resource} \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer {yourToken}'
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
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
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}',
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
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
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}',
Visão geral
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
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
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)'
Visão geral
'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çalhoX-Access-Token
com a chave de API fornecida como o valor do cabeçalho.
Formato de solicitação pós-autorização
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}'
Visão geral
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
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
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}'
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
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.
Como funciona
Os parâmetros adicionados à seção de autenticação são incluídos automaticamente em qualquer solicitação de conector.
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.
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'