1 Overview
- 1.1 Policy Requirements
- 1.2 Verified Providers
- 1.3 OAuth 2.0 Framework for Authorization Code Grant Type
  - 1.3.1 OAuth Roles
  - 1.3.2 Mapping Out the Protocol Flow
  - 1.3.3 Authorization Code Grant Flow
- 1.4 Policy Execution Order
2 Settings
3 Examples of Configuring the Generic OAuth2 API Policy with OIDC Providers
- 3.1 Google IdP Application Field Mappings
  - 3.1.1 Prerequisites
  - 3.1.2 Workflow
  - 3.1.3 Example Settings
4 Azure IdP Application Field Mappings
- 4.1 Microsoft Entra ID
  - 4.1.1 Prerequisites
  - 4.1.2 Workflow
  - 4.1.3 Example Settings
- 4.2 AD B2C Application
  - 4.2.1 Prerequisites
  - 4.2.2 Workflow
  - 4.2.3 Example Settings
5 Session Management
6 Related Content

Overview

Use this policy to authenticate a client by delegating the authentication to an OAuth2 provider. If this policy is applied, it is used to authenticate any request that does not contain credentials for any other authentication policies (such as API Key). The client is redirected to the OAuth provider to start the authentication flow. Once the flow completes, and the access token is obtained, the policy uses it to perform one or more requests to get information about the user, such as the ID and assigned role. Finally, a session cookie is returned to the client, and the client is redirected back to the requested URL. Subsequent requests authenticate based on the session cookie instead of repeating the OAuth flow. This implementation is based on the authorization code flow from Okta.

Starting in the October 2023 release, SnapLogic supports the implementation of OpenID. You can now use your OpenID Connect provider for the authentication controls in your Genric OAuth2 API policy.

The Generic OAuth2 API Policy also supports OAuth 1.0.

Policy Requirements

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.
Users must enable cookies in their browser for this policy to work with OAuth providers.

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.

OAuth 2.0 Framework for Authorization Code Grant Type

The OAuth 2.0 Authorization Code grant flow is a way for an the client to request an authorization code from an authorization server with the involvement of a user. This flow is suitable for scenarios where the client application needs to access resources on behalf of a user.

The OAuth 2.0 Authorization Code flow enables a client application to access other services securely. This is done by authenticating the user's credentials without directly exposing the user's password to the client application. As the resource owner only authenticates with the authorization server, the resource owner's credentials are never shared with the client.
The client application requests an authorization code from the authorization server, which the user approves.
The client then exchanges the authorization code for an access token, which is used to access protected resources on the user's behalf.

OAuth Roles

Client: The client is an application that requests access to resources on another resource server. The client redirects the user to the authorization server for authentication and authorization.
Resource Owner (User): The user who owns the resources to which the client application is requesting access.
Authorization Server: The authorization server authenticates the user's identity and issues authorization codes and access tokens to the application once authorization is granted.

Mapping Out the Protocol Flow

Authorization Code Grant Flow

Client Registration: The application is registered with the Identity Provider such as Ping Identity, Okta, Github, Salesforce or Azure which issues a Client ID, Client Secret and Redirect URI. These credentials are used to authenticate the application to the Identity Provider.
Policy Configuration: Field settings of the policy for the API endpoint includes:
- OpenID Discovery Document URL
- Login URL
- JWS Algorithm
- Scopes
- Access Token URL
- Client ID and Client Secret
- Redirect URI
Authorization Request: When the application needs to access resources on behalf of a user, it redirects the user to the Identity Provider's authorization endpoint, including its client ID and client secret where the authorization server sends the authorization code.
User Authentication and Authorization: The user authenticates with the Identity Provider and grants permission to the application to access their resources. If the user approves, the Identity Provider redirects the user back to the client application with an authorization code.
Token Request: The client application receives the authorization code and sends a request to the Identity Provider's token endpoint to exchange the authorization code for an access token.
Token Issuance: The Identity Provider validates the authorization code and the client's credentials. If valid, the Identity Provider issues an access token to the client application.
Resource Access: The client application uses the access token to access protected resources on behalf of the user. The access token is included in the authorization header of the HTTP request.

Policy Execution Order

The Generic OAuth2 policy executes after the other authentication policies, specifically those whose mechanisms are based on the client providing a token in the request, like the API Key or Callout Authenticator policies.

Settings

Parameter Name	Description	Default Value	Example

Parameter Name	Description	Default Value	Example
Label	Required. The name for the API policy.	Generic OAuth2	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”
Use OpenID Connect	Select to use an OpenID Connect (OIDC) vendor as the 3rd-party IdP.	Deselected	Selected
OpenID Discovery Document URL	Required. The OIDC discovery URL.	N/A
Login URL*	Required. The login URL for the client.	N/A
JWS Algorithm*	The algorithm used to generate the JSON Web Service token. You can find this in the Discovery Document URL to determine which algorithm is supported: `id_token_signing_alg_values_supported` Select one of the following algorithm types: HS256 HS384 HS512 RS256 RS384 RS512	RS256
Required Scopes	Required. The list of OAuth2 scopes required to get information about a user. See OAuth 2.0 Scopes for details. Click to add scopes.	N/A	N/A
Scope	The name of the OAuth2 scope.	N/A	user token session
Access Token URL	Required. The OAuth2 provider’s access token URL. The response from this token URL will be stored in $token and can be referenced in User Info URL below.	N/A	https://github.com/login/oauth/access_token
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
Redirect URI	The URI of the Snaplex load-balancer appended with `/api/1/rest/oauth2/callback`	N/A	https://groundplex.example.com/api/1/rest/oauth2/callback
User Info URL #1-2	These sections describe the HTTP GET requests this API policy should make to get information about a user. Limitation: The User Info URL field and settings do not support expressions that use the `asset` or `request` variables.	N/A	N/A
Trust all certificates	`Trust all certificates` for expired or self-assigned certificates.	False/Not selected	N/A
Target Path	The location to store the result of the request in the working object as a JSON-Path.	N/A	$user
URL	The destination for the request.	N/A	https://idp.example.com/user https://api.github.com/user
Query Parameters	The query parameters (name and value) to add into the URL.	N/A	N/A
Headers	The headers (name and value) to include in the request.	N/A	Authorization
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	$user.email
Roles Expression	Required. An expression that returns the list of roles this user is in.	N/A	$user.groups.map(group => group.name)
Session: Time-To-Live in Seconds	Required. The number of seconds for which the session is active.	86400	90000
OAuth State: Time-To-Live in Seconds	Required. The number of seconds for which the Oauth state is active.	300	1000
Status	Specifies whether the API policy is enabled or disabled.	Enabled	Disabled

Examples of Configuring the Generic OAuth2 API Policy with OIDC Providers

Google IdP Application Field Mappings

You can use Google Cloud Services to set up Google as an IdP for your OAuth2.0 policy. Refer to Google Cloud documentation for the account information required to fill out the Generic Oauth2 policy form.

Prerequisites

A project, with credentials
OAuth client ID.

Workflow

Go to the OAuth Consent Screen under APIs and Services.
When you create
Create an Application, choose an Application Type, and give it a name.
Add your redirect URL under Authorize redirect URIs.

Example Settings

The following table provides the mapping between the Google IdP application endpoints and the Generic OAuth2 policy OpenID field values.

Refer to Google Cloud documentation for the account information required to fill out the Generic Oauth2 policy form.

Generic Oauth Policy	Google Open ID Connect	Example Value

Generic Oauth Policy	Google Open ID Connect	Example Value
OpenID Discovery Document URL	`"authorization_endpoint"`	`"https://accounts.google.com/.well-known/openid-configuration"`
Login URL*	`"openid-configuration "`	`"https://accounts.google.com/o/oauth2/v2/auth"`
JWS Algorithm*	RS256	N/A
Scopes		`"openid"` `"email"` `"profile"`
Access Token URL	`"token_endpoint"`	`"https://oauth2.googleapis.com/token"`

Azure IdP Application Field Mappings

Microsoft Entra ID

You can use Microsoft Entra ID as an IdP for your OAuth2.0 policy.

Prerequisites

A project, with credentials
OAuth client ID.

Workflow

Go to the OAuth Consent Screen under APIs and Services.
When you create
Create an Application, choose an Application Type, and give it a name.
Add your redirect URL under Authorize redirect URIs.

Example Settings

The following table provides the mapping between the Microsoft Entra ID application endpoints and the Generic OAuth2 policy OpenID field values, where the application name is 2ada741a-1b5a-49e4-c3bd-fc2a72b698c.

Generic Oauth Policy OpenID Fields	Microsoft Entra ID Connect	Example Value

Generic Oauth Policy OpenID Fields	Microsoft Entra ID Connect	Example Value
OpenID Discovery Document URL	`Microsoft Entra ID application endpoint`	`https://login.microsoftonline.com/2ada741a-1b5a-49e4-c3bd-fc2a72b698c/v2.0/.well-known/openid-configuration`
Login URL*	`Microsoft Entra ID authorization endpoint`	`https://login.microsoftonline.com/2ada741a-1b5a-49e4-c3bd-fc2a72b698c/oauth2/v2.0/authorize`
JWS Algorithm*	`RS256`	N/A
Scopes	`openid` `email`	N/A
Access Token URL	`Microsoft Entra ID token endpoint`	`"https://login.microsoftonline.com/2ada741a-1b5a-49e4-c3bd-fc2a72b698c/oauth2/v2.0/token"`

AD B2C Application

Prerequisites

A tenant
An active subscription

Workflow

Have an active subscription.
Create a B2C tenant.
Register an app for support type for Accounts in any identity provider or organizational directory (for authenticating users with user flows)
Register another support type for Accounts in this organizational directory only (TestingB2CAPIM only - Single tenant)
Create a user flow. The user flow functions like a policy.
Use your app (for authenticating users with user flows) to get URL endpoints to set up your policy
Add an Identity Provider to your B2C tenant using your single-tenant app
Add your redirect URI to your single-tenant app https://yourtenantname.youruserflowname.com/yourtenantname.onmicrosoft.com/oauth2/authresp
Add your redirect URI, which you provided in the Generic Oauth2 to your app for support type for Accounts in any identity provider or organizational directory (for authenticating users with user flows)

Example Settings

The following table provides the mapping between the Azure AD B2C application endpoints and the Generic OAuth2 policy OpenID field values, where the name of the user workflow (policy-name) is the app name you create for user flows.

Generic Oauth Policy OpenID Fields	AD B2C Connect	Example

Generic Oauth Policy OpenID Fields	AD B2C Connect	Example
OpenID Discovery Document URL	`Azure AD B2C 2.0 Open ID Connect metadata document`	`https://example-app.b2clogin.com/example-app.onmicrosoft.com/B2C_1_sign/v2.0/.well-known/openid-configuration`
Login URL*	`Azure AD B2C 2.0 authorization endpoint`	`https://example-app.b2clogin.com/example-app.onmicrosoft.com/B2C_1_sign/oauth2/v2.0/authorize`
JWS Algorithm*	`RS256`	N/A
Scopes	`openid`	N/A
Access Token URL	`Azure AD B2C 2.0 token endpoint`	`"https://example-app.b2clogin.com/example-app.onmicrosoft.com/B2C_1_sign/oauth2/v2.0/token"`

Session Management

The OAuth2.0 API Policy might require consideration for active session management from an administrative point of view. A network issue or company policy might necessitate overriding the Time-to-Live settings. For this purpose, the following APIs allow a SnapLogic Org admin the ability to list session details and delete sessions as needed:

Purpose	API Call

Purpose	API Call
List all sessions	GET <`Load_Balancer`>/<`JCC_Host`>/api/1/rest/policy/session
List a specific session	GET <`Load_Balancer`>/<`JCC_Host`>/api/1/rest/policy/session/<`Session_Id`>
Delete a specific session	DEL <`Load_Balancer`>/<`JCC_Host`>/api/1/rest/policy/session/<`Session_Id`>
Delete all sessions	DEL <`Load_Balancer`>/<`JCC_Host`>/api/1/rest/policy/session

The session management details returned includes the session ID and user or client details upon making the API call. Below is the sample response upon using the GET HTTP method:

[
    {
        "type": "TaskSession$OauthSession",
        "username": "105450719975802175246",
        "roles": [
            "openid",
            "email",
            "profile"
        ],
        "session_id": "0f9eb160-b5ed-4cba-94ea-b5a3ae1fc9e0",
        "expires_at": 1718323653745
    },
    {
        "type": "TaskSession$OauthSession",
        "username": "105450719975802175246",
        "roles": [
            "openid",
            "email",
            "profile"
        ],
        "session_id": "79258c26-e361-46c5-9588-5301434a738a",
        "expires_at": 1718323838403
    }
]

Generic OAuth2

Overview

Policy Requirements

Verified Providers

OAuth 2.0 Framework for Authorization Code Grant Type

OAuth Roles

Mapping Out the Protocol Flow

Authorization Code Grant Flow

Policy Execution Order

Settings

Examples of Configuring the Generic OAuth2 API Policy with OIDC Providers

Google IdP Application Field Mappings

Prerequisites

Workflow

Example Settings

Azure IdP Application Field Mappings

Microsoft Entra ID

Prerequisites

Workflow

Example Settings

AD B2C Application

Prerequisites

Workflow

Example Settings

Session Management

Related Content