Service providers who use OAuth to authenticate and authorize access to their APIs require that KLS be configured with the credentials they provide.
KLS uses the OAuth configuration to obtain an access token and use that token in Webhook requests. KLS is designed to handle token refresh scenarios.
When configuring KLS, it is important to gain access to service provider documentation to understand their specific implementation, as details on use of OAuth vary from provider to provider.
Likewise, the savvy KLS user first validates their authorization configuration in a tool such as POSTMAN to validate their proposed settings prior to configuring KLS.
Service providers who use alternate authentication/authorization schemes such as Basic or Token-based do not require OAuth credentials, as their credentials are typically embedded within the webhook configuration itself.
Example 1: A Simple OAuth Request
Here, the credentials are given a name and description, the Authorization Request Method is POST, and the Content-Type is application/x-www-form-urlencoded.
The Authorization endpoint URL is specified, and no header values are required.
The body is configured with three key/value pairs, including client_id and client_secret values given by the service provider.
Example 2: An Alternate OAuth Configuration
In this example the credentials are given a name and description, the Authorization Request Method is GET, and the Content-Type is application/json.
The Authorization endpoint URL is specified with required parameter, and a single key/value pair is specified in the header.
Example 3: Another Simple OAuth Request
In this third example the credentials are given a name and description, the Authorization Request Method is POST, and the Content-Type is application/x-www-form-urlencoded.
No header values are required, and four key/value pairs are specified in the request body.
