Postman collection for OAuth 2.0 and OIDC

This guide helps you to test the CyberArk Identity OAuth 2.0 and OpenID Connect APIs using postman collection. Postman is an HTTP testing API application that allows you to monitor requests and responses.


  1. Install postman from
  2. Get access to CyberArk Identity tenant
  3. If you want to try out OpenID Connect, set up a OpenID Connect custom app on CyberArk Identity.
  4. If you want to try out OAuth 2.0 flows such as client credentials or resource owner password grant, set up a custom OAuth 2.0 client.

Import postman collection

Click on "Run in Postman" to import the collection in your postman: Run in Postman

Get started with postman collection

Once the postman collection is imported, the following variables have to be pre-filled to run the collection.


In this postman collection the user can be authenticated to CyberArk Identity either using the Start Authenticationand Advance Authentication API's or using the authorize endpoint.

If user is authenticated first using Start Authentication and Advance Authentication API's, the authorize endpoint returns the authorization code, else the authorize endpoint returns a bounce URL asking the user to authenticate first.


The variables can be added by selecting the variables tab, as shown above.

Variable nameDescription
tenant_urlThe URL of the CyberArk Identity tenant ( The URL will be used for all API requests to CyberArk Identity.
usernameThe username of the CyberArk Identity directory user
passwordThe password of the CyberArk Identity directory user
scopeThe 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_idThe 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_idThe 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_secretA 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.
stateThe client should use the content of this parameter to make sure the Code it received matches the authorization request it sent. It can be a random string.
nonceThe 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 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. It can be a random string.
service_usernameThe username of the service user. The service user is a confidential client and is used to generate tokens for client credentials and ROPG flow.
service_userpasswordThe password of the service user.

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

Variable nameDescription
bounceThis value determines if the user has been authenticated or not. The value can be found in the login redirect URI sent as a response to the authorization request.
resultApprove / deny the request. This parameter takes two values: 0, 1 (1 - approve, 0- deny). The default value is 0.
approved_scopesComma delimited list of approved scopes prompted for consent.
denied_scopesComma delimited list of denied scopes prompted for consent.
  • The variable redirect_uri is prefilled with the postman callback URL This callback URL should be added to the list of authorized redirect URIs on the custom app on admin portal.

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

The other variables will be automatically populated by the Test scripts in the corresponding requests.