Secret IDs

This table shows the ID for the symmetric encryption key to decrypt certificates, keys, and passwords in Privacy Enhanced Mail (PEM) format.

This table shows the ID for the secret to encrypt client-side sessions:

This table shows the ID for the secret to sign client-side sessions:

This table shows the ID for the secret to sign OAuth 2.0 and OpenID Connect (OIDC) JSON Web Tokens (JWTs):

This key signs the following tokens and requests:

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

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

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

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

Because Identity Cloud and the remote consent client share the HMAC secret, a malicious user compromising the client could potentially create trusted tokens. To protect against misuse, Identity Cloud also signs the token using a non-shared signing key mapped to the am.services.oauth2.jwt.authenticity.signing secret ID.

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

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

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

This table shows the IDs 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), 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 ID of the trusted CA certificate for mTLS client authentication:

This table shows the ID for the secret to decrypt ID tokens and userinfo endpoint JWTs when 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 ID for the secret to sign JWTs and objects when 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 ID of the trusted CA or self-signed certificate for mTLS client authentication when 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 ID for the secret to sign the JWTs issued to Web and Java agents:

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

This table shows the ID for the secret to encrypt the JWTs SAML 2.0 creates in session storage:

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

This table shows the IDs for the secrets to sign and encrypt SAML 2.0 elements:

⁽¹⁾ This algorithm is for compatibility purposes only; do not use it.

You can specify a custom secret ID for each hosted SAML 2.0 entity provider in a realm, which creates new secret IDs. These secret IDs can be unique to a provider, or shared by multiple providers.

For example, you can add a custom secret ID identifier named mySamlSecrets to a hosted identity provider. Identity Cloud dynamically creates the following IDs for the provider’s signing and encryption secrets:

Identity Cloud looks up the secrets with the custom secret ID identifiers. If unsuccessful, Identity Cloud looks up the secrets with the default secret IDs.