---
title: AM features that use keys
description: Features that require secrets for signing or encryption can use one of the following mechanisms:
component: pingam
version: 8.1
page_id: pingam:security:features-with-keys
canonical_url: https://docs.pingidentity.com/pingam/8.1/security/features-with-keys.html
keywords: ["Security", "OAuth 2.0", "SAML 2.0", "Features"]
page_aliases: ["security-guide:features-with-keys.adoc"]
---

# AM features that use keys

Features that require secrets for signing or encryption can use one of the following mechanisms:

* The AM keystore, configured at Configure > Server Defaults > Security > Key Store.

* The secrets API (secret stores).

Certain features *require* secret stores and some support either secret mechanism. This list outlines which features can use which secret mechanism:

* Features that only use the AM keystore

  * **User self-service**

    Requires a JCEKS keystore with a key pair alias for encryption and a key alias for signing.

    Learn more in [Create a user self-service service instance](../user-self-service/configuring-uss.html#create-uss-service).

  * **Amster**

    Requires an `sms.transport.key` key alias to export and import encrypted passwords.

    Learn more in [Create transport keys to export configuration data](../amster/transport-keys.html).

  * **IDM user self-registration**

    Requires copying signing and encryption keys from IDM into the AM keystore.

    Learn more in [Delegate user self-registration to IDM](../user-self-service/configuring-user-self-registration.html#configure-user-self-registration-idm).

* Features that use secret stores

  * **Client-side sessions**

    Require keys or secrets for signing and encrypting client-side journey and authenticated sessions.

    Learn more in [Client-side session security](session-state-configure-cookie-security.html).

  * **Authentication trees**

    Requires a key alias to encrypt values stored in the authentication tree's transient state.

    Learn more in [Store values in a tree's node states](../auth-nodes/store-values-shared-state.html#store-values-in-transient-state).

  * **OAuth 2.0 providers**

    Require a key alias for signing [client-side tokens](../am-oauth2/stateless-oauth2.html#configure-client-side-signatures) and [OpenID Connect ID tokens](../am-oidc1/managing-jwk_uri.html#oauth2-oidc-digital-signatures). Also require a key alias for encryption of client-side OAuth 2.0 access and refresh tokens.

    Learn more in [Configure client-side OAuth 2.0 token encryption](../am-oauth2/stateless-oauth2.html#oauth2-client-side-encryption).

  * **Web and Java agents**

    Web agents and Java agents communicate with AM using a built-in OAuth 2.0 provider, configured globally in AM. This communication requires a key alias for signing tokens.

    Learn more in the [Web Agents User Guide](https://docs.pingidentity.com/web-agents/2025.3/user-guide) and the [Java Agents User Guide](https://docs.pingidentity.com/java-agents/2025.3/user-guide).

  * **Remote Consent service**

    Requires a key alias for signing consent responses, and another key alias for encrypting consent responses.

    Learn more in [Remote consent](../am-oauth2/oauth2-remote-consent.html).

  * **SAML 2.0 federation**

    Requires key pairs for signing and encrypting messages, responses, and assertions; for example, a key to encrypt the JWT stored in the local storage of supported browsers.

    You could also require a key to sign exported metadata.

    Learn more in [Sign and encrypt messages](../am-saml2/saml2-encryption.html). You can find a list of the secret label mappings in [Secret label default mappings](secret-mapping.html#secret-label-mappings).

  * **Persistent cookie nodes**

    Requires a key pair alias for encryption.

    Learn more in [Set Persistent Cookie node](https://docs.pingidentity.com/auth-node-ref/8.1/set-persistent-cookie.html).

* Features that support different keystore configurations

  * **ForgeRock Authenticator (OATH), ForgeRock Authenticator (PUSH), and the WebAuthn Profile Encryption services**

    Support configuring a different keystore to encrypt device profiles. Also support keystore types that aren't available to other features.

    Learn more in [Multi-factor authentication](../am-authentication/authn-introduction-authn.html#about-mfa).

  * **AM's startup (bootstrap) process**

    Requires two password strings. Use the AM keystore as the bootstrap keystore where possible. If you configure a different bootstrap keystore, you must:

    * Keep the password strings updated.

    * Overwrite the `boot.json` file before AM starts up.

    Learn more in [Replace the AM keystore](am-keystore.html#proc-bootstrap-keystore).

* Features that require different keystore configurations

  * **Java fedlets**

    Require a keystore containing a key pair to sign and verify XML assertions and to encrypt and decrypt SAML assertions. Keystore and key information are configurable in the `FederationConfig.properties` file. Learn more in [Configure Java fedlet properties](../am-saml2/create-configure-fedlet.html#unconfigured-fedlet-properties).

  * **Security token service**

    Requires a JKS keystore for encrypting SAML 2.0 and OpenID Connect tokens. Doesn't require files to store the keystore password or the key aliases' passwords.

    Learn more in [Configure STS instances](../sts/sts-using-console.html).

  * **CSV audit logging handler**

    Requires a keystore for tamper-proofing. Doesn't require a file to store the keystore password; the password is configured in the AM admin UI. Learn more in [Configure CSV audit event handlers](../monitoring/implementing-audit.html#configuring-csv-audit-event-handlers).