Integration Service
Banner background image
Integration Service User Guide
Last updated Feb 27, 2024

Authentication Configuration

One of the big pillars for creating a Connector is identifying and correctly integrating its authentication setup. If done correctly, once the connector is published to the Integration Service catalog, users can create connections to it just like with any other connector within the catalog. All connectors reuse the authentication framework so that the full authentication flow and connection management can be handled in a unified approach.

The end-result of authentication is that any subsequent request within this connector uses the result of the authentication process for every API call. For example, a Bearer token is sent in the headers on every API call:

docs image

Connector Builder supports the following industry standards through simple configuration rather than extensive coding.

  • OAuth 2.0 Authorization code
  • OAuth 2.0 Authorization code with PKCE
  • OAuth 2.0 Client credentials
  • Basic
  • API key
  • Personal Access Token (PAT)
  • Custom
  • No authentication

Since Connector Builder ties into the Integration Service framework, defining your authentication setup is now a matter of configuration rather than a complex process. This means that the framework deals with token exchanges, refreshes, and any other such tasks. Connector Builder defaults to OAuth 2.0 Authorization code, since this is the most common vendor approach to handle authentication.

The authentication page is made out of 3 components:

  1. The Authentication type, which drives how the authentication framework reflects with additional validation for PKCE, full token exchange (for OAuth), etc. In addition, it also reconfigures the table with properties underneath so that the required properties are outlined.
    docs image
  2. The properties table can be modified with custom parameters and/or editing existing ones. Depending on the Authentication type selection in the dropdown, some fields might be mandatory and specified in red.
    Note: Making changes to this properties within this table or the Authentication type in general will invalidate the connection you might have already created within Connector Builder. There is only 1 connection during design time and it needs to be setup and tested against the latest Authentication configuration

    docs image
  3. The Authentication screen which is automatically generated based off the configuration you provided. What you see during configuration within Connector Builder is exactly the end-result that users of your Activity Pack will see.
    docs image

Authentication table configuration

Disregarding the Authentication type the loaded properties table identifies 2 items:
  1. What the user sees within the authentication screen
  2. How authentication is handled by the authentication framework
  • Every line item in the table represents a property that can or can not be overwritten by the user. In able to present a given field on screen it needs to be flagged as Yes for the Ask the user column.
  • Every line item has a Name and a Display name where the Name is what the vendor is expecting for the technical setup and the latter is of importance on how to ask this input from the user on the authentication screen.
  • Every line item holds an action menu which allows editing the property into far more detail. This is where you can state that a given property needs to be sent as a header. See more examples in the API Key section
  • Authentication table configuration

Was this page helpful?

Get The Help You Need
Learning RPA - Automation Courses
UiPath Community Forum
Uipath Logo White
Trust and Security
© 2005-2024 UiPath. All rights reserved.