Showing results for 
Search instead for 
Did you mean: 

Calls for Public CAP-API using BTP Scheduler not working

0 Kudos

Hello Community

We developed a public API using CAP (Node.js) and we have the problem that calls from BTP Scheduler are not working because of JWT Token Validation.

When the API is called from Browser (Private Window) it works fine (without authentication).

See for example Service Definition:


using {my} from '../db/schema';
@requires: 'any'  // public access !!
service HelloService {
  function helloWorld( ) returns String;


When called from BTP Scheduler the CAP Service crashes with following error message:


STDERR Error: Jwt token with audience: [
STDERR 'uaa',
STDERR 'sb-4b901e11-845c-4f75-8b94-dac50740axxx!b20811|sap-jobscheduler!b3'
STDERR ] is not issued for these clientIds: [
STDERR 'sb-HDI-xxxc_CPEA_xxxx-DB!t20811',
STDERR 'HDI-xxxx_CPEA_xxxx-DB!t20811'
STDERR at returnError (/home/vcap/deps/0/node_modules/@sap/xssec/lib/validator.js:308:25)
STDERR at /home/vcap/deps/0/node_modules/@sap/xssec/lib/validator.js:392:36
STDERR at TokenInfo.<anonymous> (/home/vcap/deps/0/node_modules/@sap/xssec/lib/tokeninfo.js:152:24)
STDERR at /home/vcap/deps/0/node_modules/jsonwebtoken/verify.js:261:12
STDERR at verificationKeySupplier (/home/vcap/deps/0/node_modules/@sap/xssec/lib/validator.js:346:28)
STDERR at process.processTicksAndRejections (node:internal/process/task_queues:95:5)


Note that BTP Scheduler Instance is NOT bound to the application. The Scheduler is running in another space. But since it is a public API without authorization and authentication, this should be possible IMO.

It seems like the Scheduler always (?) sends a token which is then validated from CAP / XSSEC. But since it is a public API without authorization, the Token should be ignored (as-if called from Browser).

The XSSEC Debug Trace has following output:


STDOUT 2024-05-25T18:06:01.060Z xssec:securitycontext Creating a XSUAA securityContext because of xsappname
STDOUT 2024-05-25T18:06:01.062Z xssec:JwksReplica Awaiting JWKS refresh because JWK with kid=key-id-1 is missing. OAuth2Service: ({"url":"","zid":"fca6e31a-67aa-46b1-a36c-f5c9cd57xxxx"})
STDOUT 2024-05-25T18:06:01.063Z xssec:JwksReplica Fetching JWKS from service {"url":"","zid":"fca6e31a-67aa-46b1-a36c-f5c9cd57xxxx"}.
STDOUT 2024-05-25T18:06:01.063Z xssec:requests fetchKeyFromXSUAA::HTTP Call with {
STDOUT headers: { 'User-Agent': 'nodejs-xssec-3' },
STDOUT method: 'GET',
STDOUT url: '',
STDOUT followRedirect: false,
STDOUT timeout: 2000,
STDOUT params: { zid: 'fca6e31a-67aa-46b1-a36c-f5c9cd57xxxx' }
STDOUT 2024-05-25T18:06:01.113Z xssec:JwksReplica JWKS received from service {"url":"","zid":"fca6e31a-67aa-46b1-a36c-f5c9cd57xxxx"}.
STDOUT 2024-05-25T18:06:01.116Z xssec:validators configured JwtAudienceValidator with clientId sb-HDI-xxxxCPEA_xxxx-DB!t208xx
STDOUT 2024-05-25T18:06:01.116Z xssec:validators configured JwtAudienceValidator with clientId HDI-xxxx_CPEA_xxxx-DB!t208xx
STDERR 2024-05-25T18:06:01.117Z xssec:validators


Does anybody have an idea how to fix this problem? Maybe @CarlosRoggan ??

IMO it should be possible for a BTP Scheduler, which is not bound to the application or running in another space / subaccount to call a public API running in CAP.

We also tried using flag "restrict_all_services" to false but this did not work.



Accepted Solutions (1)

Accepted Solutions (1)


Find following output from SAP OSS Ticket with answers from BTP Scheduler, XSSEC and CAP Teams.

It was quite difficult to discuss this topic.

From XSSEC team / perspective, there is no error.

As far as CAP team analyzed, they found out that BTP Scheduler instance sends an invalid JWT token to the CAP endpoint. And as all CAP handlers validate the authorization header if there is one (even if public or unprotected), the framework aborts with an validation error. As designed.

From BTP Scheduler team however, the response is that calling a public (unprotected) endpoint from Scheduler is not suppported. And it is not possible to disable the scheduler job from sending this invalid JWT token in the authorization header.

Funny thing is that this case worked for almost one year and then stopped suddenly. Unfortunately the root change has not been found why it stopped working or why it has worked before.

Therefore I close this question and leave it unresolved.

Answers (1)

Answers (1)

0 Kudos

Maybe @CarlosRoggan has an idea about this issue?