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.
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:
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.