Feature Request: Out-of-the-box token fetching when using code generated with the openapi-generator for talking to BTP reuse services

Is your feature request related to a problem? Please describe.

During tenant onboarding, we want to create a destination in the tenant’s subaccount. We tried to implement this by using the openapi-generator to generate code for the destination service. In order to make it work, we had to fetch the auth token for talking to the destination service ourselves.

It would be more convenient if the SDK did that for me out-of-the-box.

Describe the solution you’d like

I have already spent some thoughts and boundary conditions and possible solutions, though my list is very likely not exhaustive.

Currently, there are two options to fetch the token:

1. Do it yourself
2. Reuse the destination service’s token fetching capabilities.

Doing it myself is possible, but inconvenient.

Reusing the destination service’s token fetching capabilities is fine if the the target system is maintained as a destination anyway (e.g. SAP Successfactors). However, for reuse services, this isn’t something I’d typically do since they’re already in my VCAP_SERVICES. The destination service is an awkward example, so feel free to mentally substitute it by a different service.

My best guess for a solution currently is instead of passing a DestinationOrFetchOption to the execute function, it should be possible to specify service credentials instead (e.g. by service type, label, instance name, etc., or even a combination of these; I guess similar to how xsenv structures its input). The SDK should then be able to fetch a token with the information from the service binding and construct a destination that it can use for the actual request.

Of course, this should be tenant-aware, i.e. it should be possible for me to specify on behalf of which tenant I want to execute the request (looking at our specific scenario, even without a full user JWT!).

Additional complexity could come from some service bindings being maintained via the service manager instead of via VCAP_SERVICES / volume mounts directly.

Describe alternatives you’ve considered

We have a workaround, so all good.

Impact / Priority

Inconvenience, no timeline.

Additional context

Are you aware of the tokenServiceURL.headers.<header-key> (and analogous) properties? (See docs). This did not help us with our problem, but at least judging from the type definition/autocomplete, it looks like the SDK does not explicitly support these yet.

[mr-flannery]

Since the requested feature has been delivered and the other issues are tracked in different tickets, I’m fine with closing this issue.

[FrankEssenberger]

we can also do a quick review from our side merge it and you check out the canary release and give us feedback from your experience.