---
title: New in AM 8.1.x
description: AM 8.1.0 is a minor release that introduces new features, functional enhancements, and fixes.
component: pingam
version: release-notes
page_id: pingam::whats-new-8.1
canonical_url: https://docs.pingidentity.com/pingam/release-notes/whats-new-8.1.html
section_ids:
  am_8_1_0: AM 8.1.0
  node-versioning: Node versioning
  node-definitions-endpoint: Node definitions endpoint
  ai-agents: Identity for AI
  fips-compliance: FIPS compliance
  webauthn-conditional-ui: WebAuthn conditional UI
  android-key-webauthn: Support for Android key attestation
  radius-authentication: RADIUS authentication
  transactional-auth-tree: Transactional authentication trees
  new-auth-nodes: New authentication nodes
  ad-decision-node: AD Decision node
  backchannel-auth-nodes: Backchannel authentication nodes
  jwt-password-replay-node: JWT Password Replay node
  policy-decision-node: Policy nodes
  radius-auth-nodes: RADIUS authentication nodes
  rsa-securid-node: RSA SecurID authentication node
  logout-details: Set Logout Details node
  new-policy-cache: Policy cache
  new-cache-manager: Cache script values
  saml2-scripted-sp-account-mapper: Next-generation scripting support
  nextgen-saml-scripts: SAML 2.0 customization scripts
  nextgen-oauth2-custom-scripts: OAuth 2.0 customization scripts
  social_identity_provider_scripts: Social Identity Provider scripts
  new-nextgen-bindings: Next-generation script bindings
  new-nextgen-common-bindings: Common bindings
  scripted_decision_node_bindings: Scripted Decision node bindings
  dynamic_client_registration_scripting: Dynamic client registration scripting
  scope-validation-script-improvements: Scope validation scripting improvements
  new-global-library-scripts: Create global library scripts
  proxy-per-request: Support for configuring proxy settings per request
  saml2-improvements-8-1: SAML 2.0 IdP-initiated SSO in integrated mode
  new-redirect-tree-sp: Redirect to a tree on the remote SP
  new-saml2node-idpentityid: SAML2 Authentication node
  new-samlapp-getassertion: Scripted access to the SAML 2.0 assertion
  saml2-audit: SAML 2.0 audit logging (hosted IdP)
  application_authorization: Application authorization
  pd-support: PingDirectory support
  custom-cts-dn: Custom CTS DN for FBC installs
  authentication_node_enhancements: Authentication node enhancements
  pingone_nodes: PingOne nodes
  pingone_protect_initialize_node: PingOne Protect Initialize node
  set-detail-nodes: Set Detail nodes
  social-provider-handler-node: Social Provider Handler nodes
  persistent-cookie-nodes: Persistent Cookie nodes
  device-binding-nodes: Device Binding nodes
  oauth_2_0_oidc_improvements: OAuth 2.0 / OIDC improvements
  alignment-with-par-and-jar-specs: Closer alignment with PAR and JAR specifications
  realm-allow-unauthenticated-user-code-entry: Allow unauthenticated user code entry at the realm level
  map-custom-kids: Map custom key IDs to secrets
  oauth2-accepted-jwt-issuers: Perform OAuth 2.0 client authentication with a third-party issuer
  oauth2-enable-app-context: Enable application context for OAuth 2.0 / OIDC flows
  new-oauth2-require-exp: Require exp claim in JWT request object
  scope-validator-custom-refresh: Customize refresh token scopes with scope validation scripts
  aud-param-on-token-exchange: Support for audience parameter on token exchange requests
  test-pingone-worker-connection: Test the PingOne worker connection
  cdsso-login-template-ig: CDSSO login template for PingGateway
  uss-secrets: Secret store integration for user self-service features
  rar-support: Support for Rich Authorization Requests (RAR)
---

# New in AM 8.1.x

## AM 8.1.0

AM 8.1.0 is a minor release that introduces new features, functional enhancements, and fixes.

### Node versioning

We've made changes to AM to provide node versioning functionality. When we make changes to a node in the future, we'll create a new version of the node. Learn more in [Node versions](https://docs.pingidentity.com/pingam/8.1/am-authentication/node-versions.html).

You can create versioned nodes for your [custom Java nodes](https://docs.pingidentity.com/pingam/8.1/auth-nodes/create-versioned-nodes.html). Additionally, you can choose the version of the node to imitate in the Configuration Provider node.

Other node versioning changes include:

* Resource version `3.0` for `authenticationtrees` REST endpoint

  We've added a version-aware `3.0` resource to the `realm-config/authentication/authenticationtrees` endpoint. When sending a request to this endpoint, set the `Accept-API-Version` header to `protocol=2.1,resource=3.0`.

  Resource versions 1.0 and 2.0 are [deprecated](deprecation.html#node-versioning-endpoints).

  Learn more in [Create a tree over REST](https://docs.pingidentity.com/pingam/8.1/am-authentication/create-auth-trees.html#create-authn-tree-rest).

* Versioned node endpoints

  The `realm-config/authentication/authenticationtrees/nodes` endpoint is now versioned. Specify the version of the node in the request URL, for example: `https://am.example.com:8443/am/json/realms/root/realms/alpha/realm-config/authentication/authenticationtrees/nodes/UsernameCollectorNode/2.0`.

  Versionless node endpoints are [deprecated](deprecation.html#node-versioning-endpoints).

  Learn more in [Create a tree over REST](https://docs.pingidentity.com/pingam/8.1/am-authentication/create-auth-trees.html#create-authn-tree-rest).

* Audit logging

  The node version is logged in the [Authentication log](https://docs.pingidentity.com/pingam/8.1/monitoring/audit-logging-ref.html#authentication-log-format) under the `AM-NODE-LOGIN-COMPLETED` event.

  By default, `version` is logged only for node versions greater than `1.0`. To log `version` for all node versions, add the [`org.forgerock.am.auth.node.versioning.enable.v1.audit.detail`](https://docs.pingidentity.com/pingam/8.1/setup/server-advanced.html#org.forgerock.am.auth.node.versioning.enable.v1.audit.detail) advanced server property and set it to `true`.

### Node definitions endpoint

A new `listLatestNodeDefinitions` action on the `realm-config/authentication/authenticationtrees/nodes` endpoint provides a list of node definitions for the *latest* version of each node.

This action combines the responses from the following separate actions into a single response:

* `getAllTypes` action on the `realm-config/authentication/authenticationtrees/nodes` endpoint

* `schema`, `template` and `listOutcomes` actions on the `realm-config/authentication/authenticationtrees/nodes/node-name` endpoint

Learn more in [List latest node definitions](https://docs.pingidentity.com/pingam/8.1/am-authentication/list-latest-node-definitions.html).

### Identity for AI

We've added support for AI agents in AM. AI agents are specialized OAuth 2.0 identities that securely perform tasks on behalf of end users through a delegated token exchange process, ensuring distinct accountability and granular access control.

You can use AI agents to securely build [digital assistants](https://developer.pingidentity.com/identity-for-ai/glossary/idai-glossary.html#digital-assistant) that operate on behalf of end users, such as a chatbot on a retail website helping a user navigate products, or an internal workforce assistant acting on behalf of an employee to access enterprise tools like Salesforce.

Learn more in [AI agents](https://docs.pingidentity.com/pingam/8.1/am-oauth2/ai-agents.html).

### FIPS compliance

AM can be configured to run in a FIPS-approved mode of operation with Bouncy Castle FIPS keystores to comply with [FIPS 140-3](https://csrc.nist.gov/pubs/fips/140-3/final).

Find more information in [FIPS 140–3 compliance](https://docs.pingidentity.com/pingam/8.1/security/fips.html).

### WebAuthn conditional UI

AM now supports the WebAuthn *conditional UI*, also known as *passkey autofill*. This lets users sign in with a passkey if they've previously saved one in their browser. If they don't have a suitable passkey, the browser lets them authenticate using a different method, such as their username and password or social authentication.

This feature provides a more seamless login experience to end users and can help increase the adoption of passkeys.

Learn more in [Configure WebAuthn conditional UI](https://docs.pingidentity.com/pingam/8.1/am-authentication/authn-mfa-webauthn.html#webauthn-conditional-ui).

### Support for Android key attestation

AM now supports the [Android Key Attestation Statement Format](https://www.w3.org/TR/webauthn/#sctn-android-key-attestation) in WebAuthn requests.

Find more information in the documentation for the [WebAuthn Registration node](https://docs.pingidentity.com/auth-node-ref/8.1/webauthn-registration.html).

### RADIUS authentication

The RADIUS server service in AM now supports authentication trees. You can create a journey that's compatible with the RADIUS protocol, and then configure clients within the RADIUS server service to use that journey for authentication. Learn more in [AM as a RADIUS server](https://docs.pingidentity.com/pingam/8.1/am-authentication/radius-server.html).

Additionally, there are [new nodes](#radius-auth-nodes) to support RADIUS authentication from within a journey, where AM is acting as the RADIUS client.

### Transactional authentication trees

A transactional authentication tree only runs when AM starts a transaction, which happens when AM does one of the following:

* Initializes [backchannel authentication](https://docs.pingidentity.com/pingam/8.1/am-authentication/backchannel-authentication.html) using either the `/authenticate/backchannel/initialize` endpoint or the [Backchannel Initialize node](https://docs.pingidentity.com/auth-node-ref/8.1/backchannel-initialize.html).

* Runs a [SAML 2.0 app](https://docs.pingidentity.com/pingam/8.1/am-saml2/configure-providers.html#samlapp-tree) tree for a remote SP.

* Runs an [OAuth 2.0 app](https://docs.pingidentity.com/pingam/8.1/am-oauth2/oauth2-register-client.html#oauth2app-tree) tree when AM is acting as an authorization server.

* Enforces a [transactional authorization](https://docs.pingidentity.com/pingam/8.1/am-authorization/transactional-authorization.html) policy.

You can only configure transactional authentication trees using the REST API. Set the `transactionalOnly` property to `true` in the tree configuration.

Learn more in [Configure a transactional authentication tree](https://docs.pingidentity.com/pingam/8.1/am-authentication/configure-auth-trees.html#configure-transactional-auth-tree).

### New authentication nodes

#### AD Decision node

The [AD Decision node](https://docs.pingidentity.com/auth-node-ref/8.1/ad-decision.html) lets you verify credentials against a specified Active Directory data store.

The node also checks whether the user account is locked, disabled, or has expired.

#### Backchannel authentication nodes

The following new nodes provide [backchannel authentication](https://docs.pingidentity.com/pingam/8.1/am-authentication/backchannel-authentication.html) functionality from within a journey:

* [Backchannel Initialize node](https://docs.pingidentity.com/auth-node-ref/8.1/backchannel-initialize.html)

* [Backchannel Notification node](https://docs.pingidentity.com/auth-node-ref/8.1/backchannel-notification.html)

* [Backchannel Status node](https://docs.pingidentity.com/auth-node-ref/8.1/backchannel-status.html)

#### JWT Password Replay node

The [JWT Password Replay](https://docs.pingidentity.com/auth-node-ref/8.1/jwt-password-replay.html) node secures the user's password within an encrypted JSON Web Token (JWT). Applications, such as PingGateway, can then use a shared secret to decrypt the JWT and replay the credentials for authentication.

Learn more in [Password replay with AM](https://docs.pingidentity.com/pinggateway/2026/gateway-guide/credentials-am.html).

#### Policy nodes

* Policy Decision node

  A new [Policy Decision node](https://docs.pingidentity.com/auth-node-ref/8.1/policy-decision.html) lets you evaluate an authorization policy against resources within an authentication journey.

  You can configure the node to target a specific policy or application, or use a Configuration Provider node script to determine the policy dynamically.

  The node sets the outcome based on the policy's decision. It doesn't handle advices.

* App Policy Decision node

  The [App Policy Decision node](https://docs.pingidentity.com/auth-node-ref/8.1/app-policy-decision.html) is a specialized version of the Policy Decision node designed to simplify the evaluation of application access policies within a journey.

  It automatically identifies the policy set and resource (OAuth 2.0 client ID or SAML SP entity ID) from the journey context.

#### RADIUS authentication nodes

Two new nodes provide RADIUS authentication functionality from within a journey, where AM is acting as the [RADIUS client](https://docs.pingidentity.com/pingam/8.1/am-authentication/radius-client.html):

* [RADIUS Decision node](https://docs.pingidentity.com/auth-node-ref/8.1/radius-decision.html)

* [RADIUS Challenge Collector node](https://docs.pingidentity.com/auth-node-ref/8.1/radius-challenge-collector.html)

These nodes replace the RADIUS authentication module.

#### RSA SecurID authentication node

A new [RSA SecurID node](https://docs.pingidentity.com/auth-node-ref/8.1/rsa-securid.html) lets you perform multi-factor authentication (MFA) by integrating with RSA SecurID.

This node replaces the SecurID authentication module.

#### Set Logout Details node

A new [Set Logout Details node](https://docs.pingidentity.com/auth-node-ref/8.1/set-logout-details.html) lets you add details to the JSON response when a journey ends with the user logging out. You can also use this to add a `goto` parameter that redirects the user to a specified URL on logout.

The ability to add details to the logout response is made possible with new [logout hooks](https://docs.pingidentity.com/pingam/8.1/am-authentication/create-logout-hook.html), which let you run custom server-side logic on logout.

### Policy cache

The ability to store policy definitions in cache memory results in improved performance for policy evaluation.

Find more information in [Tune policy evaluation](https://docs.pingidentity.com/pingam/8.1/am-authorization/what-is-authz-decision.html#tune-policy-evaluation).

### Cache script values

The cache manager service lets you cache, retrieve, and manage data using the `cacheManager` binding in a Scripted Decision node script. This improves performance by storing frequently used or computationally expensive values, such as access tokens from an external service, reducing the need to fetch or calculate them on every execution.

The service automatically runs a `load()` function from a configured cache when a script requests a value that isn't in the cache. Subsequent requests return the stored value until it expires.

Learn more in [Cache script values](https://docs.pingidentity.com/pingam/8.1/am-scripting/cache-manager.html).

### Next-generation scripting support

We've added support for next-generation scripting to the following scripting contexts:

#### SAML 2.0 customization scripts

All the SAML 2.0 customization scripts are now enabled for next-generation:

* [IdP adapter](https://docs.pingidentity.com/pingam/8.1/am-saml2/custom-idp-adapter.html) ([API](https://docs.pingidentity.com/pingam/8.1/am-scripting/saml2-idp-adapter-api.html))

  Alter the processing of the authentication request.

* [IdP attribute mapper](https://docs.pingidentity.com/pingam/8.1/am-saml2/custom-idp-attribute-mapper.html) ([API](https://docs.pingidentity.com/pingam/8.1/am-scripting/saml2-idp-attribute-mapper-api.html))

  Map user attributes to SAML assertion attributes.

* [SP account mapper](https://docs.pingidentity.com/pingam/8.1/am-saml2/custom-sp-account-mapper.html) ([API](https://docs.pingidentity.com/pingam/8.1/am-scripting/saml2-sp-account-mapper-api.html))

  Map assertions to user accounts on the SP side.

* [SP adapter](https://docs.pingidentity.com/pingam/8.1/am-saml2/custom-sp-adapter.html) ([API](https://docs.pingidentity.com/pingam/8.1/am-scripting/saml2-sp-adapter-api.html))

  Modify the processing of the authentication request on the SP side.

#### OAuth 2.0 customization scripts

All the OAuth 2.0 scripted extension points can now use the next-generation scripting engine:

* [Access token modification](https://docs.pingidentity.com/pingam/8.1/am-oauth2/modifying-access-tokens-scripts.html) ([API](https://docs.pingidentity.com/pingam/8.1/am-scripting/access-token-modification-api.html))

  You can now also access the redirect URIs through the `clientProperties` script binding.

* [Authorize endpoint data provider](https://docs.pingidentity.com/pingam/8.1/am-oauth2/plugins-auth-endpoint-data-provider.html) ([API](https://docs.pingidentity.com/pingam/8.1/am-scripting//authorize-endpoint-data-provider-api.html))

* [May act](https://docs.pingidentity.com/pingam/8.1/am-oauth2/token-exchange.html) ([API](https://docs.pingidentity.com/pingam/8.1/am-scripting/may-act-api.html))

* [OIDC claims](https://docs.pingidentity.com/pingam/8.1/am-oauth2/plugins-user-info-claims.html) ([API](https://docs.pingidentity.com/pingam/8.1/am-scripting/user-info-claims-api.html))

* [Scope evaluation](https://docs.pingidentity.com/pingam/8.1/am-oauth2/plugins-scope-evaluation.html) ([API](https://docs.pingidentity.com/pingam/8.1/am-scripting/scope-evaluation-api.html))

* [Scope validation](https://docs.pingidentity.com/pingam/8.1/am-oauth2/plugins-scope-validation.html) ([API](https://docs.pingidentity.com/pingam/8.1/am-scripting/scope-validation-api.html))

* [Scripted JWT issuer](https://docs.pingidentity.com/pingam/8.1/am-oauth2/oauth2-jwt-bearer-grant.html#configure-scripted-jwt-issuer)

Learn more in [Migrate OAuth scripts to next-generation scripts](https://docs.pingidentity.com/pingam/8.1/am-scripting/access-token-modification-migrate.html).

#### Social Identity Provider scripts

We've introduced next-generation script contexts for social identity provider components. While these functions previously relied on a single legacy social identity profile transformation script, you can now use specialized scripts for:

* [Social IdP service](https://docs.pingidentity.com/pingam/8.1/am-authentication/social-idp-client-reference.html#transform-script) to transform the IdP's raw profile into a normalized object.

* [Social Provider Handler node](https://docs.pingidentity.com/auth-node-ref/8.1/social-provider-handler.html) to transform the normalized profile into an identity or managed object.

* [OIDC ID Token Validator node](https://docs.pingidentity.com/auth-node-ref/8.1/oidc-idtoken-validator.html) to map ID token attributes to local attributes.

### Next-generation script bindings

The following improvements have been made to script bindings for this release:

* `journey`: Use this new binding to identify the current journey and access information about journey configuration.

* `locales`: Use this new binding to return the localized version of a string from a translation map.

These bindings are available to the Configuration Provider node, Scripted Decision node, and Device Match node scripts.

#### Common bindings

* `utils.crypto.subtle`:

  * You can now use the ECDSA algorithm to generate keys, and to sign and verify signatures.

  * Use the new `crypto.subtle.deriveKey` method to derive a key given a base key and some random salt.

* `utils.base64url` now supports byte operations with the following new methods:

  * `String base64url.encode(byte[] toEncode)`

  * `byte[] base64url.decodeToBytes(String toDecode)`

- `httpClient`:

  * Reference an instance of the Http Client service to route requests through a proxy connection.

  * You can now access this binding from SAML 2.0 IdP scripts.

Learn more in [Script bindings](https://docs.pingidentity.com/pingam/8.1/am-scripting/script-bindings.html).

#### Scripted Decision node bindings

* `samlApplication`:

  * This binding has a new method, `getAssertion()`, that returns the assertion as a JSON map.

  * The `samlApplication` object is present in SAML 2.0 trees or set as the redirect tree on the hosted SP.

    You can also make sure the binding is available for all SAML flows by enabling the application context in the [hosted IdP](https://docs.pingidentity.com/pingam/8.1/am-saml2/saml2-reference.html#saml-idp-enable-app-context) or [remote SP](https://docs.pingidentity.com/pingam/8.1/am-saml2/saml2-reference.html#saml-sp-app-context-enabled) entity configuration.

* `identity`:

  The identity object returned by `idRepository.getIdentity()` now includes an `exists()` method. This lets you check whether the identity exists before performing further operations on the object.

Learn more in the [Scripted Decision node API](https://docs.pingidentity.com/pingam/8.1/am-scripting/scripting-api-node.html).

#### Dynamic client registration scripting

The `clientIdentity` binding has new methods to make it easier to set attributes without requiring LDAP formatting.

Learn more in the [Dynamic client registration scripting API](https://docs.pingidentity.com/pingam/8.1/am-scripting/dcr-api.html).

#### Scope validation scripting improvements

The following next-generation scripting changes have been made to improve customization and control over scope validation:

* `scopeValidatorHelper`:

  This new binding has methods that let you [customize refresh token scopes](#scope-validator-custom-refresh) and that let you trigger an `InvalidScopeException` for unauthorized or malformed scope requests.

* `availableScopes`:

  You can use this new binding to access all the scopes currently configured on the OAuth 2.0 client making the request.

Learn more in the [Scope validation API](https://docs.pingidentity.com/pingam/8.1/am-scripting/scope-validation-api.html).

### Create global library scripts

To create a global library script that can be accessed from all realms, perform an HTTP POST using the `/json/scripts` endpoint, with an `_action` parameter set to `createGlobal`.

Learn more in [Create a global library script](https://docs.pingidentity.com/pingam/8.1/am-scripting/rest-api-scripts-create.html#rest-api-scripts-create-global).

### Support for configuring proxy settings per request

AM now lets you define proxy settings at the request level.

Route a request through a proxy by configuring the `httpClient` binding to reference an instance of the Http Client service.

The service settings override the `*.system.proxy.*` advanced properties.

Learn more in [Http Client service](https://docs.pingidentity.com/pingam/8.1/setup/services-configuration.html#global-httpclient).

### SAML 2.0 IdP-initiated SSO in integrated mode

AM 8.1.0 introduces the following improvements to enable an IdP-initiated SSO flow using trees:

#### Redirect to a tree on the remote SP

Configure the hosted SP to redirect to a tree when a response is received from the IdP.

Learn more in [Redirect Tree](https://docs.pingidentity.com/pingam/8.1/am-saml2/saml2-reference.html#config-redirect-tree).

#### SAML2 Authentication node

Use the new configuration option to check that the IdP entity ID in the incoming SAML assertion matches the IdP entity ID configured for the node.

Learn more in [SAML2 Authentication node](https://docs.pingidentity.com/auth-node-ref/8.1/saml2.html).

#### Scripted access to the SAML 2.0 assertion

The `samlApplication` binding, available to Scripted Decision nodes, now includes the `getAssertion()` method, which returns the SAML assertion as a JSON map.

Learn more in [Query SAML application and authentication request](https://docs.pingidentity.com/pingam/8.1/am-scripting/scripting-api-node.html#samlapp-binding).

### SAML 2.0 audit logging (hosted IdP)

Details about the IdP and SP are now added to the Access log under the `AM-ACCESS-OUTCOME` event. The entity information is logged for SAML 2.0 flows where AM is the hosted IdP and the user has successfully authenticated. These additional details let you identify the SAML 2.0 application used in an authentication attempt.

Learn more in [Access log format](https://docs.pingidentity.com/pingam/8.1/monitoring/audit-logging-ref.html#access-log-format).

### Application authorization

To support authorization for OIDC and SAML applications within authentication journeys, the following features have been introduced:

* A new Authentication resource type includes a wildcard pattern to support unique identifiers such as OAuth 2.0 client IDs or SAML entity IDs.

* A new Customer Application Policy Set that uses the resource type is now included as a default policy set.

* Two new nodes, the [Policy nodes](#policy-decision-node) and the [\[app-policy-decision-node\]](#app-policy-decision-node), let you evaluate and enforce authorization policies directly within a journey.

Find more information in [Policy sets](https://docs.pingidentity.com/pingam/8.1/am-authorization/policy-sets.html) and [Resource types](https://docs.pingidentity.com/pingam/8.1/am-authorization/resource-types.html).

### PingDirectory support

PingDirectory is now a supported type when you're configuring an identity store.

LDIF files are also available for PingDirectory, which can be used to create the schemas required by AM.

Learn more in [Identity stores](https://docs.pingidentity.com/pingam/8.1/setup/setting-up-identity-stores.html) and [Set up directory schemas with LDIF](https://docs.pingidentity.com/pingam/8.1/installation/supported-ldifs.html).

### Custom CTS DN for FBC installs

When you're installing AM with a file-based configuration (FBC), you can now specify a custom DN for the CTS. Previous versions supported only the default CTS DN (`ou=famrecords,ou=openam-session,ou=tokens`).

Find more information in [Additional startup properties](https://docs.pingidentity.com/pingam/8.1/installation/passive-install-fbc.html#additional-startup-properties) in the FBC installation topic.

### Authentication node enhancements

#### PingOne nodes

A number of improvements have been made to the nodes that allow integration with PingOne.

##### PingOne Protect Initialize node

The following configuration properties have been added to the [PingOne Protect Initialize](https://docs.pingidentity.com/auth-node-ref/8.1/pingone/pingone-protect-initialize.html) node:

* Enable Universal Device Identification lets you tie the device payload to a non-extractable crypto key stored in the browser for content authenticity verification.

* Enable Agent Identification lets the PingOne Signals (Protect) SDK collect device attributes from the PingID Device Trust Agent.

* Timeout for Agent lets you specify the maximum time for establishing a connection with the PingID Device Trust Agent.

* Port Number for Agent lets you specify the port number to use when connecting to the PingID Device Trust Agent.

* Additional Signals SDK Initialization Options lets you pass additional signals (not included in the existing node configuration properties) to the PingOne Signals (Protect) SDK.

A number of configuration attributes that are no longer supported in PingOne Protect have been removed from this node.

#### Set Detail nodes

The [Set Success Details](https://docs.pingidentity.com/auth-node-ref/8.1/set-success-details.html), [Set Failure Details](https://docs.pingidentity.com/auth-node-ref/8.1/set-failure-details.html), and [Set Error Details](https://docs.pingidentity.com/auth-node-ref/8.1/set-error-details.html) nodes now let you set custom response headers in addition to customizing the JSON response.

#### Social Provider Handler nodes

We've made the following changes to the [Social Provider Handler node](https://docs.pingidentity.com/auth-node-ref/8.1/social-provider-handler.html):

* Added support for handling connection timeouts.

* Added the ability to specify the attribute to use to search for an existing user. This option only applies when you have an AM standalone deployment that uses an identity store other than PingDS.

  This option is also available in the [Legacy Social Provider Handler node](https://docs.pingidentity.com/auth-node-ref/8.1/legacy-social-provider-handler.html).

#### Persistent Cookie nodes

The [Persistent Cookie Decision](https://docs.pingidentity.com/auth-node-ref/8.1/persistent-cookie-decision.html) and [Set Persistent Cookie](https://docs.pingidentity.com/auth-node-ref/8.1/set-persistent-cookie.html) nodes now include support for configuring the `SameSite` attribute for persistent cookies.

#### Device Binding nodes

The [Device Binding](https://docs.pingidentity.com/auth-node-ref/8.1/device-binding.html) and [Device Signing Verifier](https://docs.pingidentity.com/auth-node-ref/8.1/device-signing-verifier.html) nodes now let you specify a clock skew between the client device and AM. This helps prevent binding failures caused by clocks being out of sync.

### OAuth 2.0 / OIDC improvements

#### Closer alignment with PAR and JAR specifications

A new advanced server property, [`am.oauth2.request.object.restrictions.enforced`](https://docs.pingidentity.com/pingam/8.1/setup/server-advanced.html#am.oauth2.request.object.restrictions.enforced) aligns AM behavior with the following specifications:

* OAuth 2.0 Pushed Authorization Requests (PAR) ([RFC 9126](https://www.rfc-editor.org/rfc/rfc9126.html))

* OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR) ([RFC 9101](https://www.rfc-editor.org/rfc/rfc9101.html#section-5.2)).

These specifications indicate the following:

* The authorization server should ignore authorize parameters outside the `request_uri`.

* When sending a JWT-Secured Authorization Request (JAR), the `request_uri` *must* be an `https` URI.

#### Allow unauthenticated user code entry at the realm level

A new setting on the OAuth2 Provider service lets you manage the device code flow configuration at the realm level.

Enabling Allow unauthenticated user code entry (under Realms > *Realm Name* > Services > OAuth2 Provider > Device Code lets users access and input a user code without first logging in during an OAuth 2.0 device code flow.

If you set the value in the global service configuration (on the Global Attributes tab) *and* in the realm service configuration (on the Device Flow tab), the realm-level setting takes precedence. If AM can't determine the realm value (for example, if the realm isn't provided in the verification URL), it uses the value set on the Global Attributes tab.

#### Map custom key IDs to secrets

You can now map custom `kid` header values for JWTs signed with the signing key to a specific secret alias.

Find more information in [Map custom key IDs to secrets](https://docs.pingidentity.com/pingam/8.1/am-oidc1/managing-jwk_uri.html#map-custom-kids).

#### Perform OAuth 2.0 client authentication with a third-party issuer

You can now configure an OAuth 2.0 client to accept a JWT from an issuer other than the client ID.

Add the alternative issuer to the [Accepted JWT Issuers](https://docs.pingidentity.com/pingam/8.1/am-oauth2/oauth2-register-client.html#accepted-jwt-issuers) list for OAuth 2.0 authentication to succeed.

#### Enable application context for OAuth 2.0 / OIDC flows

You can now access the application context for *all* OAuth 2.0 / OIDC flows through the `oauthApplication` binding by setting `Enable Application Context` in the OAuth 2.0 provider or at the client level.

Find more information in the [OAuth2 provider](https://docs.pingidentity.com/pingam/8.1/setup/services-configuration.html#enable-application-context) configuration.

#### Require `exp` claim in JWT request object

You can now enforce the inclusion of the (expiration time) `exp` claim in the request object specified at the `/oauth2/authorize` or `/oauth2/par` endpoints.

Enable the `Require exp claim in Request Object` setting in the [OAuth2 provider configuration](https://docs.pingidentity.com/pingam/8.1/setup/services-configuration.html#global-oauth-oidc).

#### Customize refresh token scopes with scope validation scripts

We've added support for dynamically adjusting the scopes granted to refresh tokens during the refresh flow.

Use a next-generation scripted scope validator to call `scopeValidatorHelper.inheritAccessTokenScopesOnRefresh()` to ensure a refresh token inherits the newly evaluated scopes granted to the access token. Previously, refresh tokens always retained their originally granted scopes.

Learn more about scope validation scripting changes in the [Scope validation API](https://docs.pingidentity.com/pingam/8.1/am-scripting/scope-validation-api.html).

#### Support for audience parameter on token exchange requests

AM now supports the `aud` (audience) parameter on token exchange requests to specify the intended audience for the issued token.

Find more information in [Token exchange](https://docs.pingidentity.com/pingam/8.1/am-oauth2/token-exchange.html).

### Test the PingOne worker connection

You can now test the connection from AM to PingOne after you configure the worker service to verify the details. Use either the AM admin UI or the `testConnection` action on the `realm-config/services/pingOneWorkerService/workers/pingone-worker-service-name` endpoint.

Learn more in [Test the connection](https://docs.pingidentity.com/pingam/8.1/setup/services-configuration.html#test-connection).

### CDSSO login template for PingGateway

The PingGateway agent in AM can now be configured to redirect to a specified URL when CDSSO fails. Add the new `gotoOnFailure` parameter to the existing template in Login URL Template for CDSSO.

Learn more in [Register PingGateway with AM](https://docs.pingidentity.com/pinggateway/2026/gateway-guide/preface.html#register-agent-am).

### Secret store integration for user self-service features

User self-service features can now use a secret store for managing the keys used to sign and encrypt snapshot tokens (JWTs).

Learn more in [Create a user self-service instance](https://docs.pingidentity.com/pingam/8.1/user-self-service/configuring-uss.html#create-uss-service).

### Support for Rich Authorization Requests (RAR)

AM 8.1.0 provides initial support for RAR, as specified in [RFC 9396: OAuth 2.0 Rich Authorization Requests](https://www.rfc-editor.org/rfc/rfc9396.html).

Learn more in [Remote consent](https://docs.pingidentity.com/pingam/8.1/am-oauth2/oauth2-remote-consent.html).

|   |                                                                                                                                                                                                                                                                                                                                             |
| - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|   | The interface stability for RAR support is Technology Preview. Technology previews offer access to new technology that is not yet supported in production. Technology preview features may be functionally incomplete and subject to change without notice. Find more details in [Interface stability](stability.html#interface-stability). |
