Bump com.sap.cloud.security.xsuaa:token-client from 3.5.7 to 4.1.2 in /sdm

[dependabot]

Bumps com.sap.cloud.security.xsuaa:token-client from 3.5.7 to 4.1.2.

Release notes

Sourced from com.sap.cloud.security.xsuaa:token-client's releases.

4.1.2

• Enforce constructor-supplied service configurations in HybridTokenAuthenticator
  • The IAS and XSUAA delegate authenticators were constructed without the configurations explicitly passed to HybridTokenAuthenticator, causing them to fall back to Environments.getCurrent() at request time. The supplied SecurityHttpClient was similarly ignored by the delegates
  • The constructor now forwards iasConfig, xsuaaConfig, and httpClient to both delegates via withServiceConfiguration / withHttpClient. Applications that follow the documented pattern of loading configurations from Environments.getCurrent() are unaffected
  • Adds HybridTokenAuthenticatorConfigurationTest with real delegates (no reflection-based mock replacement) to guard against regressions on both the IAS and XSUAA validation paths
• Update dependencies:
  • Spring Boot: 4.1.0 → 4.1.1
  • Spring Framework: 7.0.8 → 7.0.9
  • Spring Security: 7.1.0 → 7.1.1
  • Jetty: 12.1.11 → 12.1.12
  • Reactor (core & test): 3.8.6 → 3.8.7
  • JUnit Jupiter: 6.1.2 → 6.1.3
  • SpotBugs annotations: 4.10.3 → 4.10.4
  • SpotBugs Maven Plugin: 4.10.3.0 → 4.10.4.0
  • logcaptor (test scope): 2.12.6 → 2.12.7
  • Legacy Spring Boot 3.x / Spring Framework 6.x compatibility versions for the spring-security-3 module: Spring Boot 3.5.14 → 3.5.16, Spring Framework 6.2.18 → 6.2.19, Spring Security 6.5.10 → 6.5.11, Reactor 3.8.2 → 3.8.7

4.1.1

• Fix null X-App-Tid request header sent to IAS JWKS endpoint when token lacks app_tid claim
  • SapIdJwtSignatureValidator unconditionally placed the app_tid claim value as the X-App-Tid request header. When the claim is absent, token.getAppTid() returns null, causing a NullPointerException or a literal "null" header value on the outgoing JWKS request
  • The header is now only added when app_tid is present in the token; tokens without the claim omit the header entirely, which is the correct behaviour for provider-tenant requests

4.1.0

• Skip IAS proof-token validation for tokens with a single audience or no audience claim
  • SapIdJwtSignatureValidator previously gated the proof-token / forwarded-client-cert check on the presence of the ias_apis claim. It now gates on token.getAudiences().size() > 1, so the check only runs for genuine app-to-app tokens (multiple audiences) and is skipped for app-to-service tokens (single audience) and tokens with a missing/empty aud claim
  • Eliminates spurious "client certificate could not be read" failures on requests where no x-forwarded-client-cert header is expected
• Support additional JWT signature algorithms in JwtSignatureValidator. In addition to the previously supported RS256, tokens signed with the following algorithms (RFC 7518 §3.3 / §3.4 / §3.5) can now be validated:
  • RS384, RS512 (RSASSA-PKCS1-v1_5 with SHA-384 / SHA-512)
  • PS256, PS384, PS512 (RSASSA-PSS with SHA-256 / SHA-384 / SHA-512). The corresponding PSSParameterSpec is set automatically before signature verification.
  • ES256, ES384, ES512 (ECDSA on P-256 / P-384 / P-521 with SHA-256 / SHA-384 / SHA-512). The JCA name SHA*withECDSAinP1363Format is used so the raw R||S signature format mandated by RFC 7518 §3.4 is accepted directly. EC JWKs are constructed from crv/x/y with strict curve and coordinate-length validation per RFC 7518 §6.2.1.
  • Selection is driven by the JWT header alg value. Unknown values continue to be rejected with the existing "is not supported" error.
• Expose the sap_id_type claim on SapIdToken
  • New SapIdToken#getIdType() returning a typed SapIdType enum (USER, APP); resolves to null if the claim is absent or carries an unknown value
  • New TokenClaims.SAP_ID_TYPE constant
  • DefaultIdTokenExtension#isTechnicalUser now prefers the sap_id_type claim and falls back to the sub == azp heuristic for tokens issued before the claim was introduced
• Tolerate unsupported or malformed entries in a JWKS response
  • JsonWebKeySetFactory previously aborted the whole parse when a single entry resolved to an algorithm the library does not recognise (or was otherwise malformed), so an IdP adding a key for a new algorithm family broke token validation for every tenant sharing the endpoint — including tokens signed with algorithms this library DOES support
  • Each entry is now parsed in isolation: unsupported alg/kty is skipped with an INFO log, a malformed entry is skipped with a WARN, and both carry sanitized kid/kty/alg for diagnostics
  • When a caller later requests a kid that was silently dropped at parse time, the pre-throw WARN in OAuth2TokenKeyServiceWithCache now points at the earlier Skipping JWK entry log lines so the root cause is discoverable. The existing Key with kid <kid> not found in JWKS. exception message is unchanged for downstream log-based alerts
• Update dependencies:
  • Jetty: 12.1.10 → 12.1.11
  • JUnit Jupiter: 6.1.0 → 6.1.2
  • log4j2: 2.26.0 → 2.26.1
  • org.json: 20260522 → 20260719
  • SpotBugs annotations: 4.10.2 → 4.10.3
  • SpotBugs Maven Plugin: 4.10.2.0 → 4.10.3.0
  • logback-core (test scope, token-client / token-client-spring / token-client-spring-3): 1.5.25 → 1.5.34

4.0.8

... (truncated)

Changelog

Sourced from com.sap.cloud.security.xsuaa:token-client's changelog.

4.1.2

• Enforce constructor-supplied service configurations in HybridTokenAuthenticator
  • The IAS and XSUAA delegate authenticators were constructed without the configurations explicitly passed to HybridTokenAuthenticator, causing them to fall back to Environments.getCurrent() at request time. The supplied SecurityHttpClient was similarly ignored by the delegates
  • The constructor now forwards iasConfig, xsuaaConfig, and httpClient to both delegates via withServiceConfiguration / withHttpClient. Applications that follow the documented pattern of loading configurations from Environments.getCurrent() are unaffected
  • Adds HybridTokenAuthenticatorConfigurationTest with real delegates (no reflection-based mock replacement) to guard against regressions on both the IAS and XSUAA validation paths
• Update dependencies:
  • Spring Boot: 4.1.0 → 4.1.1
  • Spring Framework: 7.0.8 → 7.0.9
  • Spring Security: 7.1.0 → 7.1.1
  • Jetty: 12.1.11 → 12.1.12
  • Reactor (core & test): 3.8.6 → 3.8.7
  • JUnit Jupiter: 6.1.2 → 6.1.3
  • SpotBugs annotations: 4.10.3 → 4.10.4
  • SpotBugs Maven Plugin: 4.10.3.0 → 4.10.4.0
  • logcaptor (test scope): 2.12.6 → 2.12.7
  • Legacy Spring Boot 3.x / Spring Framework 6.x compatibility versions for the spring-security-3 module: Spring Boot 3.5.14 → 3.5.16, Spring Framework 6.2.18 → 6.2.19, Spring Security 6.5.10 → 6.5.11, Reactor 3.8.2 → 3.8.7

4.1.1

• Fix null X-App-Tid request header sent to IAS JWKS endpoint when token lacks app_tid claim
  • SapIdJwtSignatureValidator unconditionally placed the app_tid claim value as the X-App-Tid request header. When the claim is absent, token.getAppTid() returns null, causing a NullPointerException or a literal "null" header value on the outgoing JWKS request
  • The header is now only added when app_tid is present in the token; tokens without the claim omit the header entirely, which is the correct behaviour for provider-tenant requests

4.1.0

• Skip IAS proof-token validation for tokens with a single audience or no audience claim
  • SapIdJwtSignatureValidator previously gated the proof-token / forwarded-client-cert check on the presence of the ias_apis claim. It now gates on token.getAudiences().size() > 1, so the check only runs for genuine app-to-app tokens (multiple audiences) and is skipped for app-to-service tokens (single audience) and tokens with a missing/empty aud claim
  • Eliminates spurious "client certificate could not be read" failures on requests where no x-forwarded-client-cert header is expected
• Support additional JWT signature algorithms in JwtSignatureValidator. In addition to the previously supported RS256, tokens signed with the following algorithms (RFC 7518 §3.3 / §3.4 / §3.5) can now be validated:
  • RS384, RS512 (RSASSA-PKCS1-v1_5 with SHA-384 / SHA-512)
  • PS256, PS384, PS512 (RSASSA-PSS with SHA-256 / SHA-384 / SHA-512). The corresponding PSSParameterSpec is set automatically before signature verification.
  • ES256, ES384, ES512 (ECDSA on P-256 / P-384 / P-521 with SHA-256 / SHA-384 / SHA-512). The JCA name SHA*withECDSAinP1363Format is used so the raw R||S signature format mandated by RFC 7518 §3.4 is accepted directly. EC JWKs are constructed from crv/x/y with strict curve and coordinate-length validation per RFC 7518 §6.2.1.
  • Selection is driven by the JWT header alg value. Unknown values continue to be rejected with the existing "is not supported" error.
• Expose the sap_id_type claim on SapIdToken
  • New SapIdToken#getIdType() returning a typed SapIdType enum (USER, APP); resolves to null if the claim is absent or carries an unknown value
  • New TokenClaims.SAP_ID_TYPE constant
  • DefaultIdTokenExtension#isTechnicalUser now prefers the sap_id_type claim and falls back to the sub == azp heuristic for tokens issued before the claim was introduced
• Tolerate unsupported or malformed entries in a JWKS response
  • JsonWebKeySetFactory previously aborted the whole parse when a single entry resolved to an algorithm the library does not recognise (or was otherwise malformed), so an IdP adding a key for a new algorithm family broke token validation for every tenant sharing the endpoint — including tokens signed with algorithms this library DOES support
  • Each entry is now parsed in isolation: unsupported alg/kty is skipped with an INFO log, a malformed entry is skipped with a WARN, and both carry sanitized kid/kty/alg for diagnostics
  • When a caller later requests a kid that was silently dropped at parse time, the pre-throw WARN in OAuth2TokenKeyServiceWithCache now points at the earlier Skipping JWK entry log lines so the root cause is discoverable. The existing Key with kid <kid> not found in JWKS. exception message is unchanged for downstream log-based alerts
• Update dependencies:
  • Jetty: 12.1.10 → 12.1.11
  • JUnit Jupiter: 6.1.0 → 6.1.2
  • log4j2: 2.26.0 → 2.26.1
  • org.json: 20260522 → 20260719
  • SpotBugs annotations: 4.10.2 → 4.10.3
  • SpotBugs Maven Plugin: 4.10.2.0 → 4.10.3.0
  • logback-core (test scope, token-client / token-client-spring / token-client-spring-3): 1.5.25 → 1.5.34

... (truncated)

Commits

• d5e5972 Fix/hybrid token authenticator delegate configuration (#2023)
• 5427e40 Fix/sap id jwt signature null app tid (#2022)
• e61fd6b Release 4.1.0 (#2011)
• 4a77da7 fix: Sanitize x-client_cert header for IAS proof-token validation (4.0.8) (#1...
• d588235 chore: Bundle Dependabot updates for 4.1.0 (#1984)
• b25248c Merge pull request #1976 from SAP/release-4.0.7
• 5d82f47 Merge branch 'main' into release-4.0.7
• 6450c9c fix: Initialize SSLContext with explicit TrustManager (4.x) (#1980)
• d14e1aa Add missing no-arg constructor to DefaultOAuth2TokenService (#1981)
• cee9f18 Merge pull request #1972 from SAP/bugfix/xsuaa-token-extension-multitenant-ro...
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)