Failed to verify JWT - reintroduced....

Hey, When migrating from cloud-sdk 2.1.0 to 2.3.0, the following issue occurs, which is kind of related to #2211: I’m trying to execute a VDM request via a destination. The destination is determined via @sap-cloud-sdk/connectivitys getDestination function provided with a JWT issued via @sap/xssecs requests.requestClientCredentialsToken for the destination service… As worked out in #2211 and meanwhile documented in the migration guide, I’ve set iasToXsuaaTokenExchange to false. Working with @sap-cloud-sdk/connectivity@2.1.0 everything’s fine, but breaks when using @sap-cloud-sdk/connectivity@2.2.0 (or above) with the stack trace listed below. The other cloud sdk libs can be used eiter in 2.1.0/2.2.0/2.3.0, only the connectivity module causes the issue.

Stack trace:

[cds] - ErrorWithCause: Failed to verify JWT.
    at /path/to/project/node_modules/@sap-cloud-sdk/connectivity/src/scp-cf/jwt.ts:118:13
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at Function.getSubscriberToken (/path/to/project/node_modules/@sap-cloud-sdk/connectivity/src/scp-cf/destination/destination-from-service.ts:159:20)
    at Function.getDestinationFromDestinationService (/path/to/project/node_modules/@sap-cloud-sdk/connectivity/src/scp-cf/destination/destination-from-service.ts:94:7)
    ... // my user code....
Caused by:
Error: Jwt token with audience: [
  'sb-clonexxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx!byyyy|my-xsappname!bzzz',
  'uaa'
] is not issued for these clientIds: [ 'sb-myapp!txxxx', 'myapp!txxxx' ].
    at returnError (/path/to/project/node_modules/@sap/xssec/lib/validator.js:254:25)
    at /path/to/project/node_modules/@sap/xssec/lib/validator.js:306:36
    at TokenInfo.<anonymous> (/path/to/project/node_modules/@sap/xssec/lib/tokeninfo.js:140:24)
    at /path/to/project/node_modules/jsonwebtoken/verify.js:223:12
    at /path/to/project/node_modules/@sap/xssec/lib/verificationkey.js:111:24
    at KeyCache.getKey (/path/to/project/node_modules/@sap/xssec/lib/keycache.js:191:16)
    at VerificationKey.loadKeyXSUAA (/path/to/project/node_modules/@sap/xssec/lib/verificationkey.js:104:18)
    at Object.module.exports [as verify] (/path/to/project/node_modules/jsonwebtoken/verify.js:94:10)
    at TokenInfo.verify (/path/to/project/node_modules/@sap/xssec/lib/tokeninfo.js:128:20)
    at /path/to/project/node_modules/@sap/xssec/lib/validator.js:269:30 {
  cause: Error: Jwt token with audience: [
    'sb-clonexxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx!byyyy|my-xsappname!bzzz',
    'uaa'
  ] is not issued for these clientIds: [ 'sb-myapp!txxxx', 'myapp!txxxx' ].
      at returnError (/path/to/project/node_modules/@sap/xssec/lib/validator.js:254:25)
      at /path/to/project/node_modules/@sap/xssec/lib/validator.js:306:36
      at TokenInfo.<anonymous> (/path/to/project/node_modules/@sap/xssec/lib/tokeninfo.js:140:24)
      at /path/to/project/node_modules/jsonwebtoken/verify.js:223:12
      at /path/to/project/node_modules/@sap/xssec/lib/verificationkey.js:111:24
      at KeyCache.getKey (/path/to/project/node_modules/@sap/xssec/lib/keycache.js:191:16)
      at VerificationKey.loadKeyXSUAA (/path/to/project/node_modules/@sap/xssec/lib/verificationkey.js:104:18)
      at Object.module.exports [as verify] (/path/to/project/node_modules/jsonwebtoken/verify.js:94:10)
      at TokenInfo.verify (/path/to/project/node_modules/@sap/xssec/lib/tokeninfo.js:128:20)
      at /path/to/project/node_modules/@sap/xssec/lib/validator.js:269:30 {
    statuscode: 401
  }

Btw, I do not provide a custom issuer via iss property…

Do you have any suggestions on what needs to be changed when upgrading?

Thanks in advance, Tobi

[nocheintobi]

Thanks for your input, Frank! That has helped a lot.

[FrankEssenberger]

Let me ask a little different: Is the following (which in fact works and corresponds in a way to what is also mentioned in the migration guide) a suitable way to go: const token: string = await serviceToken(‘xsuaa’, {jwt: {iss: https://${tenant}.localhost:8080/uaa/oauth/token}, useCache: true}); ?

If this leads to a token which can be validated by the lib and you get the destination for the tenant later on, yes. However as I mentioned above this does not add value (not 100% sure there) compared to using the {iss:…} directly in the JWT because you create a token and validate it directly. You still need to ensure that the value for tenant is not manipulated by someone. If you have a JWT issued coming from outside of your application this is can not happen