New in AM 7.2.x

The OAuth 2.0 Provider service includes a new advanced property, Allow Client Credentials in Token Endpoint Query Parameters, that lets you include client credentials as query parameters in OAuth 2.0 token endpoint requests.

In previous AM versions, you could supply client credentials (the client_id and client_secret) as query parameters in POST requests to the /oauth2/access_token endpoint. This is now prohibited by default and you must include the credentials within the POST request body.

The new Allow Client Credentials in Token Endpoint Query Parameters setting controls this behavior and is false by default in new deployments. For security reasons, keep this property disabled to prevent client credentials from being included as query parameters.

When you upgrade an existing deployment to AM 7.2.2, this property is initially set to true for legacy support. After upgrading, you should update your scripts and clients to support the new behavior then set the property to false.

DS has introduced a new LDAP health check feature that changes how AM determines server availability. Keep-alive checks are now sent for every LDAP connection to prevent idle timeouts and separate availability checks are performed for load balanced connections.

Two new advanced server properties determine the settings for the keep-alive and availability checks:

For details, refer to Advanced properties.

To make it easier to publish keys used for remote consent, AM 7.2 provides a new JWKs URI, specifically for remote consent agents. This URI indicates where a remote consent service can obtain the keys that AM uses to sign and encrypt the consent request. These keys include:

The default JWKs URI for remote consent clients is /oauth2/consent_agents/jwk_uri.

For example, https://openam.example.com:8443/openam/oauth2/realms/root/realms/alpha/consent_agents/jwk_uri.

For social authentication through Apple, this flag indicates that the native app can send userinfo in JSON format.

For details, refer to Request Native App for UserInfo.

The Configuration Provider node lets you reference a script that builds up the node configuration, based on the node state.

For details, refer to Configuration Provider node.

The CAPTCHA node has been rewritten to support ReCAPTCHA v3. The new node has two possible outcomes (success and failure), and lets you set a score threshold. For more information, refer to CAPTCHA node.

For details, refer to Passthrough Authentication node.

The Set Custom Cookie node lets you store a custom cookie in the client.

For details, refer to Set Custom Cookie node.

The scripted implementation of the existing Java extension points lets you extend AM functionality rapidly and easily, without the need to recompile.

AM now provides JavaScript example scripts for the following extension points:

For details, refer to Sample scripts.

The addition of a new PAR endpoint as defined in RFC 9126, lets clients push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request, and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint.

For details, refer to:

A new Java system property (org.forgerock.openam.encryption.padshortinputs) pads short inputs for compatibility with Java 17.

For details, refer to Use stronger encryption algorithms.

A new advanced server property (org.forgerock.openam.authentication.forceAuth.enabled) controls the ForceAuth authentication property for chains.

For details, refer to org.forgerock.openam.authentication.forceAuth.enabled.

AM now supports JWT-secured authorization response ((JARM), which gives clients the option to receive authorization response parameters packaged in a signed, and optionally encrypted, JWT.

JARM introduces the following client configuration properties and corresponding oauth2/.well-known/openid-configuration parameters:

The supported algorithms and methods are defined in new OAuth 2.0 provider configuration.

For details, refer to response_mode.

The UMA provider service includes a number of new properties to support interactive claims gathering.

For details, refer to Claims gathering.

You can now configure a grace period on refresh tokens, that effectively lets you reuse a refresh token. This setting lets your OAuth 2.0 clients recover seamlessly, if the response from an original refresh token request is not received, because of a network problem or other transient issue. The ability to reuse refresh tokens is limited by the grace period set in the OAuth2.0 provider configuration or on the OAuth 2.0 client.

A new enabled setting in the authentication tree configuration lets you use the REST interface to disable trees that are not in use, and enable trees when they are ready to be used.

For details, refer to Enable and disable an authentication tree.

Use this node in conjunction with the Push Sender and Push Result Verifier node when collecting a challenge code from a user’s device.

Learn more in Push Wait node.

AM 7.2 adds the ability to override OAuth 2.0 provider configuration parameters with specific values at the client level.

Learn more in Create and configure a client profile.