OAuth 2.0

OAuth 2.0 is an authorization framework that lets DCKAP Integrator access certain data of another application (like e-commerce or ERP or any system). This allows us to get the users consent once with defined scope and use it further to automate things. This way, you stay in control of your information!

DCKAP Integrator supports four major grant types

1. Authorization Code

2. Authorization Code with PKCE

3. Resource Owner Credentials

4. Client Credentials

Authorization Code

Let us try to understand it with an analogy. Imagine you’ve ordered a special package from a store but can’t pick it up yourself. You ask a trusted friend to handle it for you.

1. Granting Permission: You give your friend a special authorization slip that says, "My friend is allowed to pick up this specific package for me." This slip is like the authorization code.

2. Collecting the Package: Your friend takes the authorization slip to the store. The store verifies the slip and, if it's valid, hands over the package to your friend. The package represents the access token.

3. Delivering the Package: Your friend brings the package to you. They can only pick up the package you’ve authorized and nothing more.

Now, this is what happens when you use the Authorization Code Grant of OAuth 2.0.

Configuration Steps

To create a new private system with OAuth 2.0 Authorization Code Authentication, configure the below fields along with the basic system creation fields.

Field Name	Purpose/Value
Grant Type	Authorization Code
Client Authentication	Choose Send Client Credentials in Body when Client ID and Client Secret are to be passed in the body and Send as Basic Auth Header if they are to be passed as Basic Auth Header as per your System Specification.
Add Authorization Data to	Once the access token is generated, it is sent for all API calls to get authorized. If the authorization key has to be added in the header, choose Request Headers or vice versa.
Authorization Format	The format in which the token has to be sent for all API calls. Example 1: If your system returns token as “ABCDEFGHIJKLMNOPQRSTUVWXYZ” and In API Calls if you need to send {“Authorization”: “ABCDEFGHIJKLMNOPQRSTUVWXYZ”}, then the authorization format is DYNAMIC_TOKEN. In API Calls if you need to send {“Authorization”: “Bearer ABCDEFGHIJKLMNOPQRSTUVWXYZ”}, then the authorization format is Bearer DYNAMIC_TOKEN. Example 2: If your system returns token as {“access_token”: “ABCDEFGHIJKLMNOPQRSTUVWXYZ”} and in API Calls you need to send {“Authorization”: “Bearer ABCDEFGHIJKLMNOPQRSTUVWXYZ”}, then authorization format is Bearer DYNAMIC_TOKEN[access_token]
Client ID	Client ID of your application
Client Secret	Client Secret of your application
Authorization URL	The absolute base URL for authorizing your System. Refer to your system documentation for Authorization Base URL. Ignore the query parameters part. This is the URL hit for requesting authorization code.
Token URL	The absolute token URL for requesting access token using the authorization code. Refer to your system documentation.
Scope	Scope of access you want to provide to DCKAP Integrator (Check the allowed scopes in your system documentation). When you want to grant access to more than one scope, use space to separate. Also, your access token will be usually short lived. To allow DCKAP Integrator to auto-generate the access token using refresh token without your intervention, kindly check your System’s documentation for the scope to generate access token along with refresh token. Example: api offline_access
Redirect URL	Configure this redirect URL in your system’s application

State is auto-generated internally to avoid CSRF Attacks.

Provide test connection details and test it in the credentials page by adding a new connection. When adding credentials, if the access token is generated successfully after giving consent, the credentials will be saved. If not, you will either receive an error in the pop-up window or in the Credentials page.

Authorization Code with PKCE (Proof Key Code Exchange)

This is the recommended approach

This is an additional level of security provided to mitigate the authorization code interception attack of Authorization Code Grant. To have stronger security, OAuth 2.0 has special protections like PKCE to keep the authorization code safe from third party who might try to grab it. A code verifier is required along with the authorization code to obtain the access token.

Your end system or application should have support to use Authorization Code with PKCE authentication.

All the steps are the same as in the Authorization Code process, except that the grant type is Authorization Code with PKCE, and you need to choose the transformation method. It's recommended to use SHA-256.

Resource Owner Credentials

Choose Grant Type as Resource Owner Credentials. This allows the users to provide username and password in the credentials section.

In case of confidential clients (i.e, your system requires client ID and client secret for accessing), these fields are mandatory, failing which might result in error.

Client Credentials

This is similar to resource owner credentials but the major difference is that these credentials are not the resource owner’s original credentials but rather credentials created for DCKAP Integrator by the user with a restricted access as per need. So, the credentials part doesn’t have username and password in this grant type.

OAuth 2.0 will soon be supported in dynamic workflows, add new pipes page and templates.