Use Postman collection for OAuth2.0 and OIDC

This topic shows how to test theCyberArk Identity OAuth 2.0 and OpenID Connect APIs using Postman collection. Postman is an HTTP-testing API application that enables you to monitor requests and responses.

Before you begin

Install Postman from https://www.postman.com/downloads/.
Get access to a CyberArk Identity tenant.
If you want to try out Use OpenID Connect, set up a OpenID Connect custom app on CyberArk Identity.
If you want to try out OAuth 2.0 flows such as the Use the client credentials flow or Use the resource owner password flow, set up a custom OAuth 2.0 client.

Import the Postman collection

Click Run in Postman to import the collection in Postman.

Get started with the Postman collection

Once the Postman collection is imported, you need to pre-fill the following variables to run the collection.

In this Postman collection, the user can be authenticated to CyberArk Identity either using the Start Authentication and Advance Authentication APIs or by using the authorize endpoint. If the user is authenticated first using the Start Authentication and Advance Authentication APIs, the authorize endpoint returns the authorization code. Otherwise, the authorize endpoint returns a bounce URL asking the user to authenticate first.

Add the variables by selecting the Variables tab, as shown above.

Variable name	Description
tenant_url	The URL of the CyberArk Identity tenant. For example: `https://example.my.idaptive.app` `https://example.id.cyberark.cloudp` The URL is used for all API requests toCyberArk Identity.
username	The username of the CyberArk Identity directory user
password	The password of the CyberArk Identity directory user
scope	The scope setup in the OpenID Connect web app in the tenant The scopes have to be pre-registered with the OIDC/OAuth2 client custom apps.
application_id	The application ID of the OpenID Connect/OAuth2 custom web app is configured in CyberArk Identity. This value can be found on the Settings tab of the app.
client_id	The client ID is the unique ID that CyberArk Identity issues to the client application. The client ID can be found in the Trust tab of the OIDC custom app. For OAuth 2.0 flows, the client ID is the username of the user.
client_secret	A unique code that an authorization service issues when the service registers the application. You can think of it as the password for the client application. The client secret can be found in the Trust tab of the OIDC custom app. For OAuth 2.0 flows, the client secret is the password of the user.
state	The client should use the content of this parameter to make sure that the code it received matches the authorization request it sent. This can be a random string.
nonce	The string value is used to associate a client session with an access token and to mitigate replay attacks. The value is passed through unmodified from the authentication request to the access token. If this is present in the access token, clients must verify that the nonce claim value equals the value of the nonce parameter sent in the authentication request. This can be a random string.
service_username	The username of the service user The service user is a confidential client and is used to generate tokens for client credentials and the ROPG flow.
service_userpassword	The password of the service user

The following variables are required if you want to try out OIDC consent:

Variable name	Description
bounce	This value determines whether the user has been authenticated The value can be found in the login redirect URI sent as a response to the authorization request.
result	Approve / deny the request This parameter takes two values: 0, 1 (1 - approve, 0- deny). The default value is 0.
approved_scopes	A comma-delimited list of approved scopes prompted for consent
denied_scopes	A comma-delimited list of denied scopes prompted for consent

The variable redirect_uri is prefilled with the Postman callback URL https://oauth.pstmn.io/v1/callback. You should add this callback URL to the list of authorized redirect URIs on the custom app on the Admin Portal.

The variables code_challenge, code_verifier, and code_method are also pre-filled with values. These values are required for the authorization code flow with PKCE. For more information on how to generate these values, see Integrate the authorization code flow with PKCE.

The other variables are automatically populated by the test scripts in the corresponding requests.