Securing integrations with OAuth 2.1

U+ Bank uses Pega Infinity™ to power its customer loan application portal. The scenario includes two integration directions:

• Inbound (Pega as resource server or provider): Third-party partner applications access loan status APIs hosted by Pega
• Outbound (Pega as client): Pega Case processing retrieves credit scores from external credit bureaus

The following legacy flows increase the risk to these integrations:

• The implicit grant flow, historically used by browser-based applications to obtain access tokens directly through the user agent, increases the risk of token exposure and interception
• The resource owner password credentials (ROPC) grant flow requires applications to handle user credentials directly, increasing the risk of credential theft and misuse

Together, these legacy flows expose sensitive financial records to token interception, credential theft, and unauthorized access.

By adopting OAuth 2.1-aligned practices, U+ Bank can bind authorization code exchanges to the initiating client through Proof Key for Code Exchange (PKCE) and enforce exact redirect URI validation. This reduces the risk of token misuse and unauthorized access.

OAuth 2.1 deprecates legacy patterns and establishes robust security defaults for integration design.

Deprecation of ROPC and implicit  grants

Under OAuth 2.0, single-page applications (SPAs) commonly used the implicit grant because it allowed applications to obtain access tokens directly through the browser without a backend token exchange. This approach increased the risk of token exposure in the browser environment.

Similarly, the ROPC grant required users to provide their usernames and passwords directly to the client application, increasing credential exposure and bypassing the principle of delegated authorization.

The OAuth 2.1 specification omits both the implicit grant and resource owner password credentials (ROPC) grant flows. User-delegated applications must use the authorization code grant with PKCE, while machine-to-machine integrations continue to use the client credentials grant.

Mandatory Proof Key for Code Exchange

OAuth 2.1 requires Proof Key for Code Exchange (PKCE) for all authorization code grant flows. PKCE helps prevent authorization code interception attacks by ensuring that only the client that initiated the authorization request can exchange the authorization code for tokens.

The PKCE flow uses three key parameters:

1. code_verifier: A high-entropy cryptographically random string generated by the client application
2. code_challenge: A Base64URL-encoded SHA-256 hash derived from the code_verifier
3. code_challenge_method:  The method that the client used to generate the challenge. OAuth 2.1 requires the value S256, indicating SHA-256 hashing

During the authorization request, the client sends the code_challenge and code_challenge_method to the identity provider (IdP). After the IdP returns an authorization code, the client submits the original code_verifier when requesting tokens. The IdP recalculates the challenge from the provided verifier and compares it with the previously received code_challenge. The system issues tokens only if the values match.

Strict redirect URI matching

OAuth 2.1 requires strict validation of redirect URIs to prevent authorization code interception and redirection attacks. During the authorization request, the authorization server compares the client's redirect_uri with a registered redirect URI using exact string matching. If the client includes a redirect_uri parameter in the token request, the value must exactly match the redirect_uri used in the authorization request. Legacy implementations that accepted wildcard domains or dynamic path segments increased the risk of redirecting authorization codes to unauthorized endpoints. By enforcing exact redirect URI matching, OAuth 2.1 helps ensure that the authorization server returns authorization codes and tokens only to trusted, preregistered client endpoints.

The following table lists the key security and implementation differences between OAuth 2.0 and OAuth 2.1:

To align with OAuth 2.1 requirements in Pega Infinity 26, configure both outbound and inbound integrations to enforce the updated security baseline.

Outbound integrations (Pega as client)

When Pega authenticates against an external identity provider (IdP), complete the following configuration steps:

1. Create an OAuth 2.0 Authentication Profile that uses the Authorization Code grant.
2. Enable the PKCE option. Pega generates a cryptographically random code_verifier and derives a corresponding code_challenge. The system sends the code_challenge in the authorization request and submits the original code_verifier during the token request to prove that the same client initiated the authorization flow.
3. Select Use refresh token if available checkbox to renew tokens without user interaction. You can revoke tokens.

Inbound integrations (Pega as provider)

When external systems consume Pega APIs, complete the following configuration steps:

1. Create an OAuth 2.0 Client Registration for each consuming application.
2. Select the Authorization Code grant and enable Proof Key for Code Exchange (PKCE). Pega uses the SHA-256 (S256) method to generate a code_challenge from a cryptographically random code_verifier. The generated code_challenge is 43 characters long, and Pega includes it  in the authorization request.
3. Enter exact, absolute redirect URIs in the List of redirect URIs table. Do not use wildcards or relative paths.
4. Avoid loopback URLs as redirect URIs, because Pega does not validate loopback port numbers at runtime.
5. For new designs, use the authorization code grant with PKCE for delegated user access and the client credentials grant for system-to-system access when these patterns meet the integration requirements.

The following table lists common symptoms, likely causes, and corrective actions:

Check your knowledge with the following interaction: