NPE and wrong-attribute dispatch in OAuth2 client-authentication paths (id_token_signed_response_alg)

[ayhambashtawi2-lang]

Found while independently verifying an unrelated SSRF report (GHSA-2x48-52jh-cr4g). Neither of these is a security issue — both are correctness bugs that break token issuance / client authentication for legitimately-configured clients.

Bug 1 — missing default for id_token_signed_response_alg causes an NPE at the token endpoint

• openam-oauth2/src/main/java/org/forgerock/openam/oauth2/OpenAMClientRegistration.java:508-519 (getIDTokenSignedResponseAlgorithm()) returns null if the attribute was never explicitly persisted, instead of defaulting per the OIDC Core spec (RS256).
• openam-oauth2/src/main/java/org/forgerock/openam/oauth2/StatefulTokenStore.java:283 then calls signingAlgorithm.toUpperCase() unguarded → NullPointerException.
• Impact: any client requesting the openid scope whose idTokenSignedResponseAlg was never explicitly set (e.g. created via a direct realm-config PUT rather than full dynamic registration) gets a 500/server_error from /oauth2/access_token for every grant type, instead of a token.
• Suggested fix: default to RS256 when unset, and/or null-check before .toUpperCase().

Bug 2 — client-assertion verification dispatches on the wrong client attribute

• openam-oauth2/src/main/java/org/forgerock/openam/oauth2/OpenAMClientRegistration.java:654-655 (verifyJwtIdentity()) chooses HMAC vs. asymmetric verification of an incoming private_key_jwt client assertion based on the client's id_token_signed_response_alg — which governs outgoing ID token signing, an unrelated, independently-configurable setting — instead of token_endpoint_auth_method / public_key_selector.
• A client correctly configured for private_key_jwt + jwks_uri but with id_token_signed_response_alg=HS256 (a common/default ID-token algorithm, chosen independently of how the RP authenticates) gets every asymmetric client assertion routed into verifyJwtBySharedSecret() instead of byJWKs() / byJWKsURI(), failing with JwsSigningException: Unsupported Signing Algorithm, SHA256withRSA — an internal error, not a clean invalid_client.
• Impact: breaks private_key_jwt authentication for a subset of legitimately-configured clients.
• Suggested fix: dispatch on getTokenEndpointAuthMethod() / getClientPublicKeySelector() (already used elsewhere in this class) rather than getIDTokenSignedResponseAlgorithm().

Both reproduced against current master (commit 5993d76d5c) via a local Docker instance. Happy to provide full repro steps/logs if helpful.

[vharseko]

Thanks — both confirmed and fixed in #1131.

Bug 1: exactly as you describe. AgentsRepo reads agent attributes without schema defaults, so a client created through the realm-config REST endpoint or ssoadm has no value persisted and getIDTokenSignedResponseAlgorithm() returned null (it also NPE'd in IdTokenInfo and verifyJwtIdentity, not only in StatefulTokenStore). The fallback is HS256 rather than the spec's RS256, because that is the default the schema (AgentService.xml), the console and dynamic client registration already apply — a client created through the console with the field left alone gets HS256, and the fallback keeps the two paths consistent.

Bug 2: confirmed, with one twist in the fix. verifyJwtIdentity() has four callers: two verify client-signed assertions (ClientCredentialsReader, JwtBearerGrantTypeHandler), but two verify ID tokens that OpenAM itself issued (IdTokenInfo, OpenIdConnectSSOProvider), where id_token_signed_response_alg is the right attribute. Dispatching on token_endpoint_auth_method would break those and any older client that never set the method. So the dispatch now follows the JWS header of the presented JWT: HMAC → client secret only, anything else → the client's registered public keys only (jwks / jwks_uri / x509), none → refused. Neither branch can reach the other's key material, so the header cannot be used for algorithm confusion, and OpenAM-issued ID tokens behave as before since their header matches the configured algorithm.

Your private_key_jwt + jwks_uri + id_token_signed_response_alg=HS256 case is covered by a unit test in the PR.