[ES 2825] Aud claim fix for - fapi2-security-profile-final-par-test-array-as-audience-fails

[Md-Humair-KK]

Summary by CodeRabbit

• Bug Fixes
  • Tightened client assertion token validation so audience checks are stricter when only one expected audience is configured.
  • Improved matching behavior for multi-audience tokens to allow valid audience overlap while rejecting mismatches.
  • Added coverage for success and failure cases to ensure the updated validation works consistently across strict and non-strict modes.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 2319be43-f588-4e77-99c5-c3ca0ea76163

📥 Commits

Reviewing files that changed from the base of the PR and between db78d05 and 33fe48d.

📒 Files selected for processing (2)

• oidc-service-impl/src/main/java/io/mosip/esignet/services/TokenServiceImpl.java
• oidc-service-impl/src/test/java/io/mosip/esignet/services/TokenServiceTest.java

---

Walkthrough

TokenServiceImpl.getNimbusJwtDecoderFromJwk now enforces a stricter aud claim check when the configured audience list contains exactly one entry: the JWT aud must also be a singleton equal to that value. The multi-audience fallback uses the prior anyMatch logic. Four unit tests are added to cover all branches.

Strict AUD Validation in Client-Assertion JWT

Layer / File(s)	Summary
AUD validator strict-match logic oidc-service-impl/src/main/java/.../TokenServiceImpl.java	Replaces the single anyMatch branch with a conditional: when audience.size()==1, requires the JWT aud to contain exactly one element equal to that configured value via aud.getFirst(); otherwise falls back to the prior anyMatch approach.
Unit tests for strict and non-strict audience oidc-service-impl/src/test/java/.../TokenServiceTest.java	Adds four tests: strict check passes with matching single aud; strict check fails with a multi-value aud list; strict check fails with a non-matching single aud; non-strict check passes when one of multiple aud values matches.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• mosip/esignet#1571: Previously changed TokenServiceImpl.getNimbusJwtDecoderFromJwk to validate the aud claim against a configured List<String>, which is the same code path this PR further tightens.
• mosip/esignet#1987: Also modifies TokenServiceImpl's client-assertion aud handling by resolving the effective audience from server_profile before decoding, directly adjacent to this change.

Suggested reviewers

• anushasunkada
• KashiwalHarsh

🐇 A single aud must stand alone,
No list of crowds to call its own.
One match, one claim, one tidy door—
Strict rabbit checks like never before!
🎯 Hop hop, the token's secure once more.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly points to the aud-claim validation fix and the related failing FAPI2 audience test case.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}