PKCE authorization bypass in OpenIdentityPlatform OpenAM allows intercepted authorization codes to be redeemed

Open Access Management (OpenAM) is an access management solution. Prior to 16.1.1, AuthorizationCodeGrantTypeHandler requires a code_verifier only when the realm-wide codeVerifierEnforced setting is enabled, even when an authorization code stores a code_challenge. Because that setting is disabled by default, an attacker who intercepts a PKCE-protected authorization code can omit code_verifier and redeem the code, while an explicitly incorrect verifier is rejected. Public clients are directly affected, and confidential-client exploitation additionally requires client authentication material or another redemption context. This issue is fixed in version 16.1.1.

OpenIdentityPlatform OpenAM Community Edition and the Maven artifact org.openidentityplatform.openam:openam-oauth2 are described as follows:

• The normalized record marks versions < 16.1.1 as affected.
• The CNA advisory specifically identifies versions <=16.0.6 as affected and identifies 16.1.1 as patched.
• The available evidence does not resolve the status of versions 16.0.7 through 16.1.0; those intermediate versions should not be assumed safe.
• Deployments using the default OAuth2 Provider configuration in the affected branch are described by the advisory as potentially affected, particularly when realm-wide verifier enforcement is disabled.

OpenIdentityPlatform OpenAM processes the OAuth2 authorization-code grant in the openam-oauth2 component, with the relevant logic in AuthorizationCodeGrantTypeHandler. When the authorization endpoint issues a code with a code_challenge, that code should be bound to the matching code_verifier at the token endpoint. In affected versions, the handler requires code_verifier only when the realm-wide codeVerifierEnforced setting is enabled; when that setting is disabled, verification can be skipped if the caller omits the code_verifier parameter. An explicitly incorrect verifier is still rejected, so the defect is in the missing-parameter path rather than in accepting arbitrary verifiers. The attacker must obtain or intercept an authorization code before it is exchanged for a token; public clients do not require additional client authentication material, while confidential clients require client authentication material or another redemption context that can redeem the code. The patch checks whether the authorization code stored a code_challenge, requires a verifier in that case, and validates the verifier only when the code was actually issued with a challenge.

The issue is reachable over the network through the authorization-code token exchange. The normalized record describes no required prior privileges and no user interaction, but exploitation has the important precondition that the attacker obtain or intercept a PKCE-protected authorization code. Public clients are directly exposed because no additional client authentication material is required to redeem the code; confidential clients require client authentication material or another context capable of completing redemption. Practical attack complexity is high because code interception is required. The record does not establish observed exploitation and does not identify a public exploit; the consulted advisory also names no campaign, victim, or specific exploitation indicator.

The technical result is that PKCE no longer reliably ensures that the party redeeming an authorization code knows the code_verifier bound to that code. This can produce a token carrying the permissions of the authorization code and may enable unauthorized access to resources covered by that token.

• Public clients have the more direct path because no additional client authentication material is required.
• Confidential clients retain the additional requirement for client authentication material or another context that can complete the redemption.
• The issue does not describe code execution, OpenAM administrative takeover, or loss of availability; the demonstrated impact is centered on authorization bypass and token issuance.

The flaw can result in a token being issued to a party that does not know the original code_verifier.

• For public clients, an attacker who intercepts an authorization code can obtain a token and use the permissions represented by that code.
• For confidential clients, exploitation requires additional client authentication material or another redemption context, making the preconditions more restrictive.
• A fraudulently issued token could permit access to or modification of data within the scopes and permissions represented by the authorization code.
• The available evidence describes a token-issuance authorization bypass, but does not establish OpenAM configuration changes, arbitrary code execution, or service disruption.

1. Upgrade OpenAM to the patched version 16.1.1. This is the release identified by the CNA advisory as fixing the issue.
2. If an immediate upgrade is not possible, enable the realm-wide codeVerifierEnforced setting to require code_verifier for authorization-code grants. Treat this as a temporary mitigation rather than a replacement for the official patch, because the available evidence does not establish that configuration changes address every aspect of the defect.
3. Review clients and realms that use PKCE, then confirm in a test environment that a code with a code_challenge is rejected when the matching verifier is omitted.
4. If there is evidence that authorization codes were redeemed improperly, follow the organization’s established incident-response process and review related tokens and sessions. The record does not provide a specific indicator for identifying an abused token.

1. Inventory OpenAM deployments and identify the Maven artifact org.openidentityplatform.openam:openam-oauth2, recording the exact release branch in use.
2. Review the OAuth2 Provider configuration for each realm, especially codeVerifierEnforced and the ssoadm attribute forgerock-oauth2-provider-code-verifier-enforced. This can identify configurations that expose the vulnerable path, but configuration review alone does not prove that a deployment is safe.
3. Where telemetry preserves parameter presence, review authorization-code exchanges in which the code was issued with a code_challenge but the token-endpoint request omitted code_verifier. Lack of suitable logs does not prove that the system was not exploited.
4. In a test environment, verify that a code issued with a code_challenge cannot be exchanged for a token when the corresponding code_verifier is omitted. Testing only an incorrect verifier is insufficient because the advisory identifies the missing-parameter path as the bypass.