Published Release Notes

New JWT access token format: Authorized Access Token

Pega Platform™ is changing from using opaque tokens to using JSON Web (JWT) tokens and the JWT access token format: Authorized Access Token (AAT). An AAT enables a client application to validate the server for user permissions and authorizes a specific application to access specific parts of a user’s data.

The major benefits to using the JWT format are:

• The JWT is a self-contained token that has authentication information, expire time information, and other user-defined claims digitally signed.
• A single token can be used with multiple applications.
• The tokens are short-lived and can minimize damage if transport security is compromised, as the token signature is verified.
• As the token is verified with the signature, there is no need to verify against a database, thus reducing latency (usually important for Web APIs).

For more information, see Understanding authorized access tokens.

Improvements to OAuth 2.0 Services with Token Introspection Service and Token Denylist Service

Increase the security of user sessions by using the newly supported Token Introspection and Denylist services for OAuth 2.0.

Token Introspection service

Use the Token Introspection service to validate JSON Web Tokens (JWT). The Token Introspection service requires authentication. 

Pega now uses OAuth 2.0 access tokens called Authorized Access Tokens (AAT). 

Token Introspection service endpoint

The Token Introspection service endpoint provides the information about the status of access token and refresh token. Token introspection can be used to validate if a given token is still active or inactive. The token introspection endpoint determines whether the token is valid. The status indicates whether an access token or refresh token is valid or invalid: 

• Valid tokens have the “active”:true status
• Invalid tokens have the “active” :false status.

The inactive status can also be due to revocation. 

Token Denylist service

You can add tokens to the deny list in cases where suspicious activity might have occurred. The Token Denylist service provides a method for denying user access to the application by revoking the user's access token. This service can prevent a token from being used more than the specified number of times, which can be helpful in preventing replay attacks. Stolen tokens should be revoked using this service. A GET API is also available to get the list of denied tokens.

Keys endpoint

Pega Platform™ is changing from using opaque tokens to JSON Web (JWT) tokens. If this JWT is used by any other system, the public key is needed for signature verification. A new endpoint is exposed to provide these public keys in JWK format: https://host:port/prweb/api/oauth2/v1/token/keys.

For more information, see OAuth 2.0 Management Services.

Enhanced refresh token strategy

You now have more precise control over your refresh token expiration strategy. When a refresh token is enabled, you can choose to set its initial expiration based on the value provided by the IDP. The refresh token expiry can be derived from IDP’s session timeout when SSO is used with external IDP for user authentication in the authorization code grant flow. You can also specify a separate refresh token expiration strategy based on your use-case. 

These can be configured in the OAuth2 Client registration rule form.

For more information, see Enhanced refresh token strategy.

Tamper-proof Pega Web Mashup loading

To protect your application from hackers, Pega Web Mashup is now loaded in a more secure way. The system generates a channel ID in the mashup code for validation on the server, before passing the mashup request. 

For more information, see Creating a mashup.

Upgrade impact

After an upgrade to Pega Platform 8.5, existing mashups, which do not have the channel ID parameter in their code, cannot load and users see the access control warning.

What steps are required to update the application to be compatible with this change?

If you need to maintain full availability of the mashup during the upgrade of the production environment, perform the steps in Migrating existing mashups.

Support for React-based components in Pega Infinity applications

React-based components can now conveniently be enabled in any existing Pega Infinity™ application without the need to migrate the application to the full React UI. By selecting a single option, you can enable and experience some of the most modern functionalities, such as intuitive and comfortable landing page authoring, or the more efficient React-based tables.

For more information, see Enabling Cosmos React UI for landing pages.

Enhancements to token lifetime limits

Pega Platform™ uses OAuth 2.0 authorization codes, access tokens, and refresh tokens to provide flexible token-based security for applications. Expiration settings for these codes and tokens now adhere to certain strict value range based on industry leading practices. For example, the lifetime specified for the authorization code must be in the range 1-600 seconds.

These can be configured in the OAuth2 Client registration rule form.

For more information, see OAuth 2.0 Management Services.

Better support for custom PDF fonts

Pega Platform™ now supports loading custom fonts for PDF files from a binary file by using the CSS @font-face rule. With this enhancement, your application can generate PDF files that use custom fonts without relying on a dedicated font folder or a cloud bundle. As Pega moves away from folder-based solutions, you can migrate font management to a binary rule for quicker development and improved maintenance.

For more information, see Generating PDFs from your UI.

Improving basic access control

Pega Platform™ has implemented a new basic access control (BAC) to protect your application from unauthorized server calls from otherwise authenticated users.

For more information, see Access Control Checks.

Upgrade impact

After you upgrade to Pega 8.5, all the functionality in the model configurations that use auto-generated controls and actions continues to work as before. However, you must secure any customized JavaScript in your application layer that makes AJAX (server) calls  by using registration or encryption mechanisms.

What steps are required to update the application to be compatible with this change?

After upgrade, to migrate custom JavaScript functionality, see Access Control Checks.

PegaWAI ruleset deprecated in 8.5

Accessibility functions that were contained in the PegaWAI ruleset are now integrated into the main Pega Platform™. Consequently, the user interface in your applications now features accessibility functions out of the box, so you no longer need to use the PegaWAI ruleset to ensure accessible behavior in your application.

For more information, see Building an accessible UI.

Tags disappear from Rich Text Editor source mode

When you use Rich Text Editor in HTML source mode, some tags disappear from the markup, which causes backward compatibility issues and data loss.

Cause

Pega Platform™ version 8.5.5 introduced the DOM Purifier security plugin. The plugin removes potentially vulnerable tags, including custom tags, from the raw HTML code in the Rich Text Editor source mode.

Workaround

You can disable the DOM Purifier plugin by adding the the window.disableDomPurifier = true markup to the userWorkForm HTML fragment rule.

Alternatively, as of Pega Platform version 8.5.6, you can add a tag to the allow list by including the window.rteCustomAllowedTags = ['myCustomTag'] snippet in the userWorkForm HTML fragment rule. 

In Pega Platform versions 8.5.6 to 8.6, the iframe tag is added to the allow list by default.