Secret labels

This table shows the label for the secret to encrypt client-side access tokens:

This table shows the labels for the secrets to sign client-side access tokens:

The secret label mappings used to authenticate OAuth 2.0 clients:

⁽¹⁾ Map the am.applications.oauth2.client.identifier.secret dynamic secret label to override the OAuth 2.0 client’s Client secret property, where identifier is the value of the Secret Label Identifier set in the client configuration.
⁽²⁾ Map the am.applications.oauth2.client.identifier.jwt.public.key dynamic secret label to override the OAuth 2.0 client’s Client JWT Bearer Public Key, where identifier is the value of the Secret Label Identifier set in the client configuration.
⁽³⁾ Map the am.applications.oauth2.client.identifier.mtls.trusted.cert dynamic secret label to override the OAuth 2.0 client’s mTLS Self-Signed Certificate, where identifier is the value of the Secret Label Identifier set in the client configuration.
⁽⁴⁾ Map the am.applications.oauth2.client.identifier.id.token.enc.public.key dynamic secret label to override the OAuth 2.0 client’s Client ID Token Public Encryption Key, where identifier is the value of the Secret Label Identifier set in the client configuration.

This table shows the labels for the secrets to sign remote consent requests:

If you select an HMAC algorithm for signing consent requests (HS256, HS384, or HS512), PingOne Advanced Identity Cloud uses the Remote Consent Service secret, not an entry from the secret store.

This table shows the label for the secret to decrypt remote consent responses:

If you select an algorithm other than RSA-OAEP-256 for decrypting consent responses, PingOne Advanced Identity Cloud uses the Remote Consent Service secret, not an entry from the secret store.

This table shows the labels for the secrets for the example remote consent service:

The secret label for salting hashes in OAuth 2.0 and OIDC flows.

Use this secret label to override Subject Identifier Hash Salt in the provider configuration.

This secret can’t be rotated.

This table shows the labels for secrets to decrypt OIDC request parameters:

For confidential clients, if you select an AES algorithm (A128KW, A192KW, or A256KW) or the direct encryption algorithm (dir), PingOne Advanced Identity Cloud uses the Client Secret from the profile, not an entry from the secret store.

The following use the Client Secret:

Store only one secret in the Client Secret field.

For details about encryption options, refer to the OIDC specification.

This table shows the labels for secrets to sign OIDC tokens and backchannel logout tokens:

For confidential clients, if you select an HMAC algorithm for signing ID tokens (HS256, HS384, or HS512), PingOne Advanced Identity Cloud uses the Client Secret from the profile instead of an entry from the secret store.

This table shows the label of the trusted CA certificate for mTLS client authentication:

This table shows the label for the secret to decrypt ID tokens and userinfo endpoint JWTs when PingOne Advanced Identity Cloud acts as a relying party (RP) of the social identity provider service:

The public key is exposed at the /oauth2/connect/rp/jwk_uri endpoint.

For details, refer to Social authentication.

This table shows the label for the secret to sign JWTs and objects when PingOne Advanced Identity Cloud acts as a relying party (RP) of the social identity provider service:

The public key is exposed at the /oauth2/connect/rp/jwk_uri endpoint.

For details, refer to Social authentication.

This table shows the label of the trusted CA or self-signed certificate for mTLS client authentication when PingOne Advanced Identity Cloud acts as a relying party (RP) of the social identity provider service:

The public key is exposed at the /oauth2/connect/rp/jwk_uri endpoint.

For details, refer to Social authentication.

This table shows the label for the secret to sign the JWTs issued to Web and Java agents:

This table shows the label for the secret to encrypt sensitive data in the secure state of an authentication journey:

The following table shows the secret label mappings used to encrypt and sign persistent cookies for the Set Persistent Cookie node and Persistent Cookie Decision node:

⁽¹⁾ The am.authentication.nodes.persistentcookie.encryption label overrides the value for Persistent Cookie Encryption Certificate Alias in the Core authentication attributes.

⁽²⁾ Map the am.authentication.nodes.persistentcookie.identifier.signing dynamic secret label to override the HMAC Signing Key node property, where identifier is the value of the HMAC Signing Key Secret Label Identifier.

This table shows the label for the secret to sign SAML 2.0 metadata:

The following table shows the secret label mappings used to sign and encrypt SAML v2.0 elements, and to enable mTLS authentication between entity providers:

⁽¹⁾ This algorithm is for compatibility purposes only. Avoid its use.

⁽²⁾ For artifact resolution requests only, the SP uses the certificates mapped to this secret label for mTLS authentication to the remote IDP. These certificates are exported with <KeyDescriptor use="signing"> in the SP metadata.

⁽³⁾ The SP uses the certificate mapped to this secret label for basic authentication. If you set a Secret Label Identifier, and PingOne Advanced Identity Cloud finds a mapping to am.applications.federation.entity.providers.saml2.identifier .basicauth, PingOne Advanced Identity Cloud uses this secret and ignores the value of the Password field. For basic authentication, there is no default secret label for the realm, or globally.

You can specify a custom Secret Label Identifier for each SAML v2.0 entity provider in a realm. PingOne Advanced Identity Cloud generates new secret labels that can be unique to the provider, or shared by multiple providers.

For example, you could add a custom secret label identifier named mySamlSecrets to a hosted identity provider. PingOne Advanced Identity Cloud then dynamically creates the following secret labels, which the hosted identity provider uses for signing and encryption:

PingOne Advanced Identity Cloud attempts to look up the secrets with the custom secret label identifier. If unsuccessful, PingOne Advanced Identity Cloud looks up the secrets using the default secret labels.

This table shows the label for the Google hardware attestation root certificate, which is used to increase confidence that the keys used by bound Android devices are valid, have not been revoked, and use hardware-backed security storage.

Refer to Verifying hardware-backed key pairs with Key Attestation in the Android developer documentation.

The following table shows the secret label mappings for CA certificates used by the httpclient script binding to secure HTTP requests.

⁽¹⁾ Map the am.services.httpclient.mtls.clientcert.identifier.secret dynamic secret label to the certificate to be used by the httpclient script binding when making HTTP requests. The identifier is the value of the Client Certificate Secret Label Identifier set in the HTTP Client service configuration.

⁽²⁾ Map the am.services.httpclient.mtls.servertrustcerts.identifier.secret dynamic secret label to the truststore of certificates that verify the server certificate. The identifier is the value of Server Trust Certificate Secret Label Identifier set in the HTTP Client service configuration.

This table shows the labels for secrets to encrypt the certificate used to authenticate Policy Configuration service connections:

For confidential clients, if you select an HMAC algorithm for signing ID tokens (HS256, HS384, or HS512), PingOne Advanced Identity Cloud uses the Client Secret from the profile instead of an entry from the secret store.

This table shows the label for secrets to sign the Amazon Simple Notification Service access key used by the Push Notification service.

The secret label mapping overrides the SNS Access Key Secret set in the service configuration.