Client secret

Client secret access

The client secret endpoint is available to users or worker applications only if they have a superset of the application’s role assignments.

Access to the application’s client secret is restricted based on the accessing user’s or application’s role assignments. For example, if a client has the Environment Admin role, an actor with an Identity Admin role cannot see the client secret. This restriction addresses privilege escalation issues by preventing the Identity Admin user from doing things with the client that the Identity Admin role assignment does not allow.

Applications client secret API operations

The Applications client secret endpoints support the following operations:

For hands-on experience with the Applications API endpoints, click the Run in Postman button below to download a Postman collection that you can import and open in your local Postman application.

Applications secret data model

Property Description
environment A string that specifies the environment associated with the application.
secret A string that specifies the secret ID that is used to sign access tokens. The secret value has a minimum length of 64 characters per SHA-512 requirements when using the HS512 algorithm to sign ID tokens using the secret as the key.

Response codes

Code Message
200 Successful operation.
201 Successfully created.
400 The request could not be completed.
401 You do not have access to this resource.
403 You do not have permissions or are not licensed to make this request.
404 The requested resource was not found.
500 An unexpected error occurred.

Note: You need the Client Application Developer role to perform operations on application resources.

Endpoint examples

Get an application secret

An application resource’s secret is a required parameter when you submit a client_credentials request to the PingOne authorization server. The application’s secret attribute value has a minimum length of 64 characters according to SHA-512 requirements when using the HS512 algorithm to sign ID tokens using the secret as the key.

The GET /environments/{environmentId}/applications/{applicationId}/secret operation returns the specified application resource’s secret attribute.

curl -X GET "{environmentId}/applications/{applicationId}/secret" \
-H "Authorization: Bearer jwtToken"

The response data looks like this:

    "_links": {
        "self": {
            "href": ""
        "environment": {
            "href": ""
        "application": {
            "href": ""
    "environment": {
        "id": "0bda42bc-d54f-449f-8d46-d5b8990c43ba"
    "secret": "68tO2tfqRWZ~DLZ1Dfi8rptBNgKz..."

Update an application secret

The following sample shows the POST /environments/{environmentId}/applications/{applicationId}/secret operation to generate a new client_secret value for the specified application resource. This request does not take any parameters in the request body. The application ID is specified in the request URL.

curl -X POST "{environmentId}/applications/{applicationId}/secret" \
-H "Authorization: Bearer jwtToken"