OAuth 2.0 Client Credentials

Overview

You can use this policy to authenticate users with a token in your OAuth 2.0 environment. This implementation is based on the Client Credential flow from Okta.

Authentication Policy Requirement

All Authentication policies require the Authorize By Role policy to authenticate the API caller correctly. For example, you can configure this policy to add the role “admin” to the client and then configure the Authorize By Role policy to authorize users with that role.

Verified Providers

SnapLogic verified the following Authentication providers for this policy:

This policy might work with other authentication providers not listed above but has not been tested and verified.

Known Issue

We do not support Azure AD for the policy because Azure AD does not provide an introspection endpoint.
Workaround: Use the JWT credentials in the Generic OAuth2 policy to authenticate with Azure AD.

Prerequisites

The Oauth2 authentication server must be configured to accept the client ID/secret from the basic auth header during introspection.

OAuth 2.0 Framework for Client Credentials Grant Type

The OAuth 2.0 Client Credentials grant flow is a way for an application (the client) to directly request an access token from an authorization server without involving a user. This flow is suitable for scenarios where the client application needs to access its own resources or when user authentication is not necessary.

The OAuth 2.0 Client Credentials Policy lets a client app access other services securely, without needing to know or store any user passwords in SnapLogic's OAuth2 environment to authenticate using its client ID and client secret. The client requests an access token from the authorization server, which it can then use to access protected resources on its own behalf. The authorization server provides a token introspection endpoint to validate the access token as an additional layer of security to the Client Credential OAuth2 framework.

OAuth Roles

  • Client: The client is an application that is requesting access to resources on another web service. The client authenticates itself using its own credentials (client ID and client secret).

  • Authorization Server: The authorization server authenticates the user's identity and issues access tokens to the application once authorization is granted.

Mapping Out the Protocol Flow

cc-policy-workflow.png

Client Credentials Grant Flow

  • Client Registration: The application is registered with the Identity Provider such as Ping Identity, Okta, Auth0, which issues Client ID, Client Secret, and Token Introspection Endpoint. Client ID and Client Secret are used to authenticate the application to Identity Provider.

  • Policy Configuration: Configuration of the policy for the API endpoint with Client ID, Client Secret, and Token Introspection Endpoint.

  • Token Request: When the application needs to access the API endpoint, it sends a request to the Identity Providers token endpoint, including its client ID, client secret.

  • Token Issuance: Identity Provider validates the application's credentials and, if they are correct, issues an access token to the application. This access token represents the authorization on behalf of the application to access the API endpoint.

  • Resource Access: The application can now use the access token to access the API endpoint. The application includes the access token in the Authorization header or query of its API requests as configured in the Client Credentials OAuth2 Policy.

  • The access token is made available in the expression scope $token in the Policy wizard.

  • Access tokens are typically short-lived and expire after a certain period.

  • The authorization server can revoke the access token for security reasons before it expire.

Policy Execution Order

The OAuth 2.0 Client Credential policy executes after early-stage request validation policies, like IP Restriction.

Settings

Parameter Name

Description

Default Value

Example

Parameter Name

Description

Default Value

Example

Label

Required. The name for the API policy.

OAuth2 Client Credential

GitHub OAuth 2.0 Policy

When this policy should be applied

An expression enabled field that determines the condition to be fulfilled for the API policy to execute.

For example, if the value in this field is request.method == "POST", the API policy is executed only if the request method is a POST.

N/A

request.method == “POST”

Introspection Endpoint

Required. The mechanism for client servers to obtain information about the access token. The response from this token introspection endpoint will be stored in $response and can be referenced in User ID Expression and Roles Expression.

N/A

https://auth.pingone.com/2f6b6ab3-1fa7-4a7d-ba4d-00dbebd6d056/as/introspect

Client ID

Required. The ID of the application registered with the OAuth2 provider.

N/A

jdoe@beignet.com

Client Secret

Required. The client secret for the application registered with the OAuth2 provider.

N/A

chocolatE

Extract into $token

Required. Specifies the location to find the key in the request. If one of the given locations is not found, this API policy will pass the request through to the next API policy.

N/A

N/A

Custom Header Keys

The names of the headers that can contain the key. If more than one header is given, they will all be checked. Click + to add more custom header keys.

N/A

X-API-Key

Custom Query String Parameter

The names of the query parameters that can contain the key. If more than one name is given, they will all be checked. Click + to add more custom query string parameters.

N/A

access_token

Authorization Type

If the key is in the Authorization header, this value is used as the “type” to check.

Token

Key

Extract User Info

Required.  Specifies how to extract information about the user from the working object.

N/A

N/A

User ID Expression

Required. An expression that returns a string to be used as the user ID.

N/A

$response.email

Roles Expression

Required. An expression that returns the list of roles this user is in.

N/A

$response.groups.map(group => group.name)

Time-To-Live in Seconds

Required. The number of seconds the token is valid for before it is re-validated.

600 (10 minutes)

700

Status

Specifies whether the API policy is enabled or disabled. 

Enabled

Disabled

Example to Configure the OAuth 2.0 Client Credentials API Policy with Ping Identity

Prerequisites

  • Apply Authorization by Role Policy

  • Verified Authentication Providers for this Policy, such as Okta or Ping Identity.

Example Workflow with Ping Identity Authentication Provider

 

You can use Ping Identity for the authentication process:

  1. Set up the application in Ping identify to obtain the Client Credentials and Token Introspection Endpoint for use in the Policy.

    pingidentity-urls.png

     

  2. Use the obtained Client Credentials and Token Introspection Endpoint in the Policy setup:

     

Parameter Name

Field Type

Example

Parameter Name

Field Type

Example

Label*

String

SnapLogic OAuth2 Policy

When this policy should be applied

String/Expression

request.method == “POST”

Introspection Endpoint*

String/Expression

https://auth.pingone.asia/92888efd-6423-4f73-9523-ae8fa6c99cee/as/introspect

Client ID*

String/Expression

0a781dd3-744c-4795-924d-b72b71c93a5f

Client Secret*

String/Expression

OwPmby3VbPpMJjKG5vXG4QciClg2xZw6oXnrXvDufRBIgbOHK5-PXvlLg0ml.DDG

Extract into $token*

N/A

 

Customer Header Key

String/Expression

X-API-Key

 

Custom Query String Parameter

String/Expression

query

 

Authorization Header Type

String

token

Extract User Info*

N/A

 

User ID Expression*

String/Expression

User

 

Roles Expression*

String/Expression

staff

Time-To-Live in Seconds*

String/Expression

600 (10 minutes)

Status

Dropdown List

Enabled


See Also