Published Release Notes

Support for OAuth 2.0 authorization code grant type

Pega Platform™ now supports the OAuth 2.0 authorization code grant type, which allows Pega Platform to act as an OAuth 2.0 access token provider for native applications on mobile and other devices. By using the authorization code grant type for mobile clients, you no longer need to implement a variety of standards for various authentication providers. The authorization code grant type also supports the Proof Key for Code Exchange standard (PKCE) for securing public clients.

For more information, see Creating and configuring an OAuth 2.0 client registration.

Use client-based access control to support EU GDPR requirements

You can use client-based access control (CBAC) to satisfy the data privacy requirements of the European Union General Data Protection Regulation (GDPR) and similar regulations. By using client-based access control, you can identify the personal data of clients and automatically process requests to view, update, or remove the data in a secure manner. You can also enforce restrictions on the use of this data in application functions.

For more information, see Client-based access control.

Data encryption support for system data

You can now control system-level data security by using data encryption in Pega Platform™. Encryption of system-level data improves the overall security of your system.

For more information, see Configuring the platform cipher and Configuring a keystore for a master key from a custom source.

All search data is encrypted

All search data in Pega Cloud deployments is now encrypted, both at rest and in transit. The encryption of search data makes search compliant with regulatory requirements.

For more information about search, see Full-text search.

Authentication service for basic credentials

A new type of authentication service is available for authenticating operators by using basic credentials (user ID and password). The default Pega Platform™ login is now an instance of this type of authentication service. All basic credentials authentication services include mobile authentication with the OAuth 2.0 protocol and Proof Key for Code Exchange (PKCE). You no longer have to create a custom authentication service to support mobile applications.

For more information, see Configuring a basic authentication service.

Unauthenticated sessions transition seamlessly to authenticated

A new authentication service type allows a guest user to use an application without logging in, and to be prompted to authenticate later in the session. This enhancement supports scenarios such as online shopping portals where a user can browse for items and load a shopping cart as a guest but be prompted for credentials at checkout.

For more information, see Configuring an anonymous authentication service.

Create single sign-on authentication services from App Studio

You can create and enable single sign-on (SSO) authentication services from a new landing page in App Studio. From this new landing page you can also configure new SAML and OpenID Connect authentication services to provision users. For more information, see Creating a SAML SSO authentication service and Creating an OIDC SSO authentication service.

Protect against insecure deserialization

Deserialization is the process of rebuilding a data stream into a Java object. The Open Web Application Security Project (OWASP) has identified insecure deserialization as one of the top 10 security vulnerabilities for web applications. Pega Platform™ protects against this vulnerability by using filters that prevent deserialization of suspect data streams. You can configure these filters from the Deserialization Blacklist landing page.

For more information, see Configuring the deserialization filter.

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.