Authentication

​

Standard non-authenticated HTTP requests

You can use HTTP requests without authentication, if the service provider or web server receiving the request does not require authentication.

​

Authenticated HTTP requests to existing service providers

HTTP Actions can be used with most of the Blink connection types to send authenticated requests to existing service providers in Blink. For example, to send an authenticated request to GitHub’s API, use a GitHub connection.

​

Authenticated HTTP requests to unsupported service providers

Blink adds support for additional service providers on a weekly basis. To use Actions with a service provider that is not currently supported, there are two options:

1. Contact the Blink team to request integration with a new service provider. Contact us.
2. Use generic HTTP Actions to communicate with unsupported service providers, as explained below.

​

Using generic HTTP actions to communicate with unsupported service providers

HTTP Actions can be used with one of the four HTTP connection types to send authenticated requests to service providers that aren’t currently supported by Blink:

1. Basic Authentication
2. Bearer Authentication
3. Custom Authentication
4. Custom 2 Legged (OAuth 2.0) Authentication

​

Basic Authentication

Authenticate using the Basic authentication standard.

​

Bearer Authentication

Authenticate using the Bearer authentication standard.

​

Custom Authentication

Authenticate using a custom authentication. You can set 3 different headers values to be sent in each request.

​

Custom 2 Legged Authentication

Authenticate using a custom 2 legged authentication, also known as OAuth 2.0.

​

Examples

Since two-legged authentication can be both versatile and complex, please refer to the following detailed explanations of the connection parameters’ behavior.

Token Extraction Path

The token extraction path parameter is responsible for the correct extraction of the authentication token from the returning response. For example:

The server returns the following payload:

{
  "token": "myToken",
  "expiry": 7999
}

The correct Token Extraction Path value is token.

The server returns the following payload which contains nested fields:

{
  "2lo_token":
  {
    "token": "myToken",
    "expiry": 7999
  }
}

The correct Token Extraction Path value is 2lo_token.token.

Expiry Method and the Accompanying Parameters

The expiry method parameter is responsible for handling the expiration of the authentication token correctly.

Currently, we support the following types:

• The expiry value is extracted from the token request response.

  In this case, alongside the authentication token, the response payload contains a token expiration value. The following parameters accompany this expiration type:

  • Expiry Extraction Path is responsible for the extraction of the expiry value. It has identical logic as the Token Extraction Path parameter.
  • Expiry Type is responsible for the valid evaluation of the expiry value. We currently support: The response contains the duration of validity of the token in seconds, The response contains the expiration timestamp of the token in Unix timestamp format 1152478800 and The response contains the expiration timestamp of the token in date-time format 2006-07-10T15:04:05Z02:00.

• The expiry value is extracted from a JWT header, given that the token itself is a JWT.

  In this case, the authentication token is of JWT format and contains in a JWT header the expiration value. The following parameter accompanies this expiration type:

  • JWT Header Name is responsible for the header name that the expiration time is located in. By default, this value is exp but may vary.

• The expiry value is constant.

  In this case, the authentication token expires after a set amount of time after creation. The following parameter accompanies this expiration type:

  • Default Expiry is the expiry time in seconds in which after the initial request, the token will expire.

Content Type and Body

The content type and body parameters are responsible for how the token request payload that is sent in the initial request. For example: We currently support the following content types:

For each example we will use the Body value of grant_type: client_credentials, client_id: myClientID, client_secret: myClientSecret

application/json

{
    "grant_type": "client_credentials",
    "client_id": "myClientID",
    "client_secret": "myClientSecret"
}

application/x-www-form-urlencoded

grant_type=client_credentials&client_id=myClientID&client_secret=myClientSecret

Advanced Parameters

Under advanced parameters you can find the following parameters:

Headers is responsible for the header in the initial token request.

Disable SSL Enforcment is responsible for disabling SSL enforcement for the initial token request. Note that this doesn’t affect the actions that use the connection.

Zero Trust Parameters are responsible for all zero trust handling for all action using the connection.