PR description

Problem

For OIDC / SASL_OAUTHBEARER flows using librdkafka’s built‑in OIDC helper, we currently hard‑require that the JWT payload contain a sub claim. If the IdP omits sub or uses another claim (for example client_id) as the primary subject, librdkafka fails token acquisition with an error such as:

Failed to acquire SASL OAUTHBEARER token: Expected JSON JWT response with "sub" field

Fix

We have introduced a new config sub_claim_name using which customers can provide a different claim. The claim value will be honored and used for client side validation.

Note
Requires users to keep broker and client configs aligned for the subject claim name to avoid confusion and consistency.

Testing

Unit tests

To test the core JWT payload parsing and claim extraction logic inside rd_kafka_oidc_token_try_validate() in isolation (no broker, network, oidc server).

1. Default Configuration & Backward Compatibility
   Implicit Default Behavior: Validate that when sub.claim.name is not provided, the system defaults to extracting the subject from the "sub" claim.
   Legacy Parity: Ensure that existing JWTs containing only the "sub" claim continue to be processed correctly, maintaining no regressions for standard OIDC flows.

2. Explicit Claim Configuration (KIP-768 Parity)
   Custom Claim Extraction: Verify that setting sub.claim.name (e.g., to client_id) successfully extracts the value from the specified field instead of the hardcoded "sub" key.
   Configuration Precedence: Test that when both "sub" and a custom claim (e.g., "client_id") coexist in a JWT, the system honors the user-defined configuration over the OIDC default.

3. Error Handling & Validation Logic
   Missing Claim Detection: Verify that providing a sub.claim.name that does not exist in the JWT triggers a specific "Claim not found" error, rather than failing on a hardcoded "sub".
   Empty Value Rejection: Ensure the system rejects empty string subjects with a "non-empty value required" error, addressing previous bugs where empty strings passed silently.
   Invalid Configuration Recovery: Validate that if sub.claim.name is set to an empty string, the system gracefully falls back to the OIDC default ("sub") to ensure continuous operation.

4. librdkafka & Java Client Alignment
   Functional Parity: Ensure all scenarios are cross-validated against the Java KIP-768 implementation to guarantee identical extraction logic and exception triggers (e.g., ValidateException equivalents).

Integration tests

• To validate end-to-end OIDC authentication against a real Kafka cluster (via trivup) with different sasl.oauthbearer.sub.claim.name configurations
• The trivup setup requires changes for returning JWT response with multiple claims

Design Doc