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.
- Install postman from https://www.postman.com/downloads/
- Get access to CyberArk Identity tenant
- If you want to try out OpenID Connect, set up a OpenID Connect custom app on CyberArk Identity.
- 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:
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.
|tenant_url||The URL of the CyberArk Identity tenant (https://example.idaptive.app). The URL will be used for all API requests to CyberArk 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 the Code it received matches the authorization request it sent. It 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 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_username||The 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_userpassword||The password of the service user.|
The following variables are required if you want to try out the OIDC consent.
|bounce||This 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.|
|result||Approve / deny the request. This parameter takes two values: 0, 1 (1 - approve, 0- deny). The default value is 0.|
|approved_scopes||Comma delimited list of approved scopes prompted for consent.|
|denied_scopes||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. 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 https://identity-developer.cyberark.com/docs/authorization-code-flow-with-pkce#code-verifier-and-code-challenge
The other variables will be automatically populated by the Test scripts in the corresponding requests.
Updated 6 months ago