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.

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.

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.

Addition of Data Access Tab to access control policy condition rules

You can now select associations and declarative index classes when creating access control policy condition rules. The Column source field in the policy condition can now accept properties from available associations and indexes. For ease of reference, the selected associations and indexes are available on the new Data Access tab. 

Using the new tab, you can build complex authorization models in which access restrictions for a class depend on the attributes present in the associated and indexed classes, along with the attributes in the current class. For example, a project management application can now separately maintain project lists for each operator and use that information to restrict read/write access to unique projects.

The information available on the new Data Access tab reflects rule form changes, which are similar to the existing functionality of the Report Definition in the Application Data Model. 

For more information, see Creating an access control policy condition.

Addition of Servlet Management

Pega Platform™ now has Servlet Management in Pega Cloud® Services, which provides a simple and secure way to make changes to Pega Platform servlet definitions.

Servlet Management provides Pega Cloud Service clients with solutions to manage servlet configurations with self-service options. This reduces the cycle time for delivering configuration changes in Pega Cloud Service installations while also improving upgrade reliability. 

For more information, see Servlet management.

Upgrade impact

Clients with no application servlet customizations will not experience an impact. If you upgrade from Pega Platform version 8.5 or earlier and, prior to the upgrade, the Pega Cloud team provided your application servlet customizations, then following the upgrade, you must manually add, remove, or modify your servlet customizations in your upgraded application using this servlet management landing page in Pega Platform.

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

To manually move your pre-upgrade servlet customizations as appropriate or add new ones to your upgraded application using the new servlet management landing page, follow the steps in Adding a servlet.

Cosmos React-UI supports custom authentication

Pega Platform™ now supports custom authentication in applications that use Cosmos React-UI. Depending on the needs of your users and the functionality of your application, you might need to write custom authentication schemes to meet specific requirements. 

Clients that use custom authentication in their applications can now take advantage of the Cosmos React-UI.

For more information, see Securing Cosmos React-UI applications.

Integration and security tab now divided into two tabs

The Integration and Security tab is now two separate tabs on the Application Definition form: Integration and Security. While the content of these two tabs are related, they function more effectively as separate tabs. The Security tab now includes the Authentication section, so you can add existing authentication services to your Application Definition to more effectively manage the security of your application. 

For more information, see Security tab of the Application Definition.