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

[dependabot]

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

Release notes

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

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

• Fix IAS proof-token validation regression under Istio / Kyma with credential-type: X509_GENERATED
  • SapIdJwtSignatureValidator was setting the x-client_cert request header directly from X509Certificate#getPEM(). When the certificate originates from Istio's x-forwarded-client-cert (XFCC) header, the PEM includes -----BEGIN CERTIFICATE----- / -----END CERTIFICATE----- delimiters and CR/LF line breaks
  • Since 4.0.0, the token-client HTTP transport uses Java 11's HttpClient, which enforces RFC 7230 and rejects any header value containing CR/LF with IllegalArgumentException (surfaced as "Token signature can not be validated because: invalid header value: <PEM>"). Every authenticated request behind Istio failed proof-token validation as a result
  • The header value is now sanitized to bare base64-encoded DER (PEM delimiters and all whitespace stripped) before being placed on the wire. The IAS JWKS endpoint accepts this form. A new X509Certificate#getLeafCertificateAsHeaderValue() accessor keeps the sanitization next to the PEM parsing; getPEM()'s existing contract is unchanged
  • JavaHttpClientAdapter additionally fails fast with a message naming the offending header key (not the value, which may be sensitive) if a header value ever contains CR/LF, turning any future regression from a misleading "invalid header value: <PEM>" into an actionable transport-layer error
• Update dependencies:
  • Spring Boot: 4.0.6 → 4.1.0
  • Spring Framework: 7.0.7 → 7.0.8
  • Spring Security: 7.0.5 → 7.1.0
  • Jetty: 12.1.9 → 12.1.10
  • Reactor: 3.8.2 → 3.8.6
  • JUnit: 6.0.3 → 6.1.0
  • SpotBugs annotations: 4.9.8 → 4.10.2
  • SpotBugs Maven Plugin: 4.9.8.3 → 4.10.2.0
  • org.json: 20251224 → 20260522
  • logcaptor: 2.12.2 → 2.12.6
  • assertj-core (samples): 3.24.2 → 3.27.7
  • maven-surefire-plugin: 3.5.5 → 3.5.6
  • jacoco-maven-plugin: 0.8.14 → 0.8.15
  • central-publishing-maven-plugin: 0.10.0 → 0.11.0
• Fix junit-bom import in the root pom — entry was missing <type>pom</type><scope>import</scope>, so JUnit platform/jupiter versions were silently resolved through Spring Boot's BOM. Now correctly imported and ordered ahead of spring-boot-dependencies so junit-bom wins for all JUnit 6 artifacts.

... (truncated)

Changelog

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

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

• Fix IAS proof-token validation regression under Istio / Kyma with credential-type: X509_GENERATED
  • SapIdJwtSignatureValidator was setting the x-client_cert request header directly from X509Certificate#getPEM(). When the certificate originates from Istio's x-forwarded-client-cert (XFCC) header, the PEM includes -----BEGIN CERTIFICATE----- / -----END CERTIFICATE----- delimiters and CR/LF line breaks
  • Since 4.0.0, the token-client HTTP transport uses Java 11's HttpClient, which enforces RFC 7230 and rejects any header value containing CR/LF with IllegalArgumentException (surfaced as "Token signature can not be validated because: invalid header value: <PEM>"). Every authenticated request behind Istio failed proof-token validation as a result
  • The header value is now sanitized to bare base64-encoded DER (PEM delimiters and all whitespace stripped) before being placed on the wire. The IAS JWKS endpoint accepts this form. A new X509Certificate#getPEMHeaderValue() accessor keeps the sanitization next to the PEM parsing; getPEM()'s existing contract is unchanged
  • JavaHttpClientAdapter additionally fails fast with a message naming the offending header key (not the value, which may be sensitive) if a header value ever contains CR/LF, turning any future regression from a misleading "invalid header value: <PEM>" into an actionable transport-layer error
• Update dependencies:
  • Spring Boot: 4.0.6 → 4.1.0
  • Spring Framework: 7.0.7 → 7.0.8
  • Spring Security: 7.0.5 → 7.1.0
  • Jetty: 12.1.9 → 12.1.10
  • Reactor: 3.8.2 → 3.8.6
  • JUnit: 6.0.3 → 6.1.0
  • SpotBugs annotations: 4.9.8 → 4.10.2
  • SpotBugs Maven Plugin: 4.9.8.3 → 4.10.2.0
  • org.json: 20251224 → 20260522
  • logcaptor: 2.12.2 → 2.12.6
  • assertj-core (samples): 3.24.2 → 3.27.7
  • maven-surefire-plugin: 3.5.5 → 3.5.6
  • jacoco-maven-plugin: 0.8.14 → 0.8.15
  • central-publishing-maven-plugin: 0.10.0 → 0.11.0
• Fix junit-bom import in the root pom — entry was missing <type>pom</type><scope>import</scope>, so JUnit platform/jupiter versions were silently resolved through Spring Boot's BOM. Now correctly imported and ordered ahead of spring-boot-dependencies so junit-bom wins for all JUnit 6 artifacts.

... (truncated)

Commits

• 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...
• 5639c8b refactor: Use UriUtil.expandPath in getUaaDomainTokenEndpoint
• c90ae22 refactor: Use UriUtil.expandPath in getUaaDomainTokenEndpoint
• 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)

[dependabot]

Superseded by #575.