Issue

After updating to Pega Platform™ 25.1.1 or decommissioning Hazelcast caching and clustering functionality, clients encounter OAuth token authorization errors. 

Symptoms and Impact

Observed exceptions include: 

• Response 401 Unauthorized error occurred with new access token com.pega.platform.integrationcore.client.email.EmailClientException: The specified object was not found in the store., Default folder Root not found

• Caused by: com.pega.platform.integrationcore.client.email.EmailClientException: Access is denied. Check credentials and try again. 

• Caused by: com.pega.pegarules.pub.PRRuntimeException: Failed while retrying to fetch accesstoken for clientID =
  com.pega.pegarules.pub.services.OutboundMappingException: Could not acquire fresh access token   

• Caused by: com.pega.pegarules.pub.PRRuntimeException: Unable to obtain access token for client details in authentication profile
  configured for connector. Please check the logs for more details 

Steps to Reproduce

1. Update deployment to Pega Platform '25.1.1 or otherwise remove/decommission Hazelcast from the deployment. 

2. Leverage the same Client ID in Authentication Profiles meant for the same external OAuth client registration. 

Root Cause

This is an implementation issue related to a token caching design change. 

When decommissioning Hazelcast (which can be done from releases 23.1.4, 24.1.3 and 24.2) or when updating to Pega Platform ‘25.1.1, centralized token caching changes from a shared global cache to a node-local cache.  There is a gap in how OAuth caches persist in the database. 

Problems occur when multiple users share the same client ID, which is against best practices. 

• Using Hazelcast deployment/ Before upgrade (24.x) 

  • Hazelcast is used as a global cache, allowing all nodes to share OAuth tokens. 

  • Tokens are consistently retrieved from the shared cache. 

• After upgrade (25.1.x) 

  • Hazelcast is removed, and token caching becomes node-local. 

  • If a token is not found in the local cache, Pega queries the database. 

  • The database query filters tokens only by: 

    • Client ID 

    • Scope 

    • Tenant ID 

    • Operator ID 

  • Username is not included, and there is no column to store it. 

Impact of Current Design

• When multiple users share the same client ID, multiple tokens may exist in the database. 

• The system may retrieve the first matching token, which could belong to a different user. 

• If the retrieved token does not correspond to the expected user, authentication failures will occur.

Local Change

Users on the following Pega Infinity releases can request a hotfix:

• Pega Platform release 25.1.2 - HFIX-D1621 
• Pega Platform release 25.1.3 - HFIX-D1681

Solution

Replace the use of the OAuth password grant with a more secure grant type (for example, Authorization Code with PKCE or Client Credentials), as the password grant is deprecated and no longer considered secure. 

Alternatively, configure a unique client ID per Authentication profile and user.  If the same client ID is present in different authentication rules it can cause inconsistent product behavior, and this configuration will be blocked in future releases. 

Follow these steps to configure a separate OAuth 2.0 Client IDs for each service account:   

1. In Azure SPN, register separate client applications for each user. 

2. Create separate Authentication Profile rules in Pega, each with its own ClientID. 

3. Configure each integration/connector to use the appropriate authentication profile. 

References

Configuring an OAuth 2.0 authentication profile 

Removing Hazelcast from your deployment