OAuth 2.0: Client Credentials Grant

Introduction

This article provides detailed information about how Appian can connect to systems that use the OAuth 2.0 Client Credentials grant. Designers can configure these integrations using a connected system.

Token Request Sequence

The OAuth 2.0 framework is defined by the ITEF RFC 6749 standard.

Appian supports the authorization code and client credentials grant types.

Unlike the Authorization Code grant, the Client Credentials grant is used when access is being requested on behalf of an application, not a user. As a result, configuring authentication with Client Credentials has fewer steps.

This standard lays out the sequence of steps involved with the Authorization Code grant. There are three main roles in this sequence:

  • Client - The system initiating the resource request. In this case, Appian.
  • Authorization Server - The server that is ensuring that the application requesting resources has the proper permissions.
  • Resource Server - The server that holds the desired resources.

The following sequence diagram describes the steps involved in a successful authorization, with a resource returned to the client.

images:client_credentials_sequence_diagram.png

The first part of the authorization process involves the client sending a token request to the authorization server. The authorization server determines whether the credentials are valid, as well as whether the application has granted the permissions being requested. If it has, the authorization server returns an access token to the client.

This access token will allow the client to request whatever resources were approved by the application.

Important Design Considerations

There are several important design considerations when using the client credentials flow.

It is very important to review and understand the requirements in the third-party system for a successful OAuth connection.

Registration in the Third-Party System

In order for Appian to successfully connect to the desired resources, you will have to register the connection in the third-party system. This is typically done under a third party system's Developer UI. The terminology varies, but registration usually requires creating an application or project in that system.

When registering an app or project in a third-party system a couple things need to be considered:

  • Access to the third-party application or project: Because the OAuth 2.0 application or project in the third-party system will contain a client secret, essentially the password for the OAuth connection, an appropriate user should be selected to register the application or project.
  • Determine where scope should be defined: A registered application's scope may need to be configured in Appian or in the registered application. Be sure to refer the other system's documentation to know where to define scope.

Parameters Set in the Connected System

A successful connection using the Client Credentials grant requires several configuration parameters to be set in an Appian connected system.

/client-credentials-parameters

The following parameters from the third-party system will need to be entered into the connected system. Refer to the third-party's documentation for more information.

Field Description
Client ID Required. ID provided by the third-party system during the registration process.
Client Secret Required. The password provided by the third-party system during the registration process. This field is masked to prevent unauthorized users from seeing and should be treated as a password.
Scope Optional. Defines what resources need to be accessed from the resource server. Depending on what system Appian is connecting to, permissions may be configured in the Developer UI rather than using a scope. In these cases, a default scope value may be specified in their documentation.
Token Request Endpoint Required. The endpoint that provided the access token for the specified resources. This value can typically be found in the third-party's documentation.
FEEDBACK