BTP Destination with Client Credentials stop working

[JuanjoGersol]

Dear experts,

I am working in a complex CAP implementation and we have found a behavior that we think it may be an issue in the BTP destination service or CAP framework.

In our project we have processes with restricted users rights, those processes at some point need to retrieve data without those restrictions, so to solve this problem we used a destination with OAuth2 client credentials where a system-user is maintained, this way the data selection overcome the security implementation. The solution works nice, but after some time, it starts returning error 401 (UNAUTHORIZED) for all the requests triggered over this destination. After a restart of the service where the usage is done, the connectivity works again.

The set of calls that leads to this problem:

• service1 performs a call to service2 with restricted user
• service 2 needs unrestricted data from service1 so it triggers a select back to this service (over the client authenticated destination).

We have been checking and debugging the requests and the only thing I can say is that req.user is anonymous and as the service requires authenticated-user the request is not authorized, after a service restart the connection works for a while, and req.user is the right one.

Our request is as simple as a selection, over the ext service:

const ext = cds.connect.to('clientcredentialsdest'); 

ext.run(SELECT...)

After some investigation, we think we solved the problem by just encapsulating the service call into a new transaction:

const ext = cds.connect.to('clientcredentialsdest');

ext.tx(async (tx) => { tx.run (SELECT...) }

Any clue about what can be the problem?

Edit: the solution I proposed did not work. The destination is still returning 401 after some idle time.


Thank you!

[bob_den_os]

When using OAuth2 the tokens have a validity time. Are you checking whether the token is still valid before sending the request ? If the token has timed out it is required to either follow the refresh token flow or the token request flow to retrieve a new token.

[JuanjoGersol]

Is this required when you are using CAP cds.connect.to?

We understand that the use of the destinations is to make transparent to the developer the procedure to request and renew the oauth process.

In any case, the system works properly for a while, we think that after some idle time of the service, maybe after the night where nobody uses it, the service start returning 401, but the reason is not the validity of the token that we checked in the debugger that is still valid, but because the CAP framework is not providing the user information in the request.

Right now the only workaround we found is to develop a logic to trigger a selection from service2 to service1 every 5 seconds to keep the service active. We are still not sure if the workaround works.

[martinstenzig]

bob.den.os , I would have expected the Cloud SDK to handle the Oauth time out?!

How do I get access to the token expiration from the CAP level?