Add Node.js part to Outbound Authentication by vkozyura · Pull Request #2596 · capire/docs

vkozyura · 2026-05-28T08:27:05Z

No description provided.

PDT42

Perhaps this guide should use the Java / Node.js switch, if that is still a thing? The examples and required steps seem pretty disconnected.

PDT42 · 2026-06-15T08:50:58Z

+::: details Java configuration explained
+
 The `type` property activates the protocol for exchanging business data and must be offered by the provider [CDS service](https://github.com/capire/xflights-java/blob/6fc7c665c63bb6d73e28c11b391b1ba965b8772c/srv/data-service.cds#L24).
 The `model` property needs to match the fully qualified name of the CDS service from the imported model.
 You can find CDS service definition of `sap.capire.flights.data` in file `target/cds/capire/xflight-data/service.cds` resolved during CDS build step.
 The `binding.name` needs to point to the shared identity instance and `options.url` together with `http.suffix` provides the required location of the remote service endpoint.
 Finally, `onBehalfOf: systemUser` specifies that the remote call is invoked on behalf of a technical user in context of the tenant.

+:::


Move this block to right after the Java specific example?

PDT42 · 2026-06-15T08:54:47Z

+::: details Node.js configuration explained
+
+The `kind` property activates the protocol for exchanging business data (same as `type` in Java).
+The key in `cds.requires` must match the fully qualified CDS service name (e.g., `sap.capire.flights.data`), which is the same name used in `cds.connect.to()`.
+The `credentials.url` provides the full endpoint URL including the service path `/hcql/data`.
+The `forwardAuthToken: true` enables direct forwarding of the incoming JWT token to the provider service - this is suitable for co-located services that share the same identity instance, as the token is already valid for the provider.
+
+:::


IMO, this could / should point to: https://cap.cloud.sap/docs/guides/integration/reuse-and-compose#configuring-required-services and https://cap.cloud.sap/docs/guides/integration/reuse-and-compose#binding-required-services, instead.

PDT42 · 2026-06-15T08:55:56Z

+
 ::: tip
-On behalf of `systemUser` works both in pure single tenant and in pure multitenant scenarios.
+On behalf of `systemUser` (Java) works both in pure single tenant and in pure multitenant scenarios.


In the updated structure, this jump back to Java systemUser is very disconnected. What is the / Is there an equivalent in Node.js?

PDT42 · 2026-06-15T08:57:31Z


-Additionally, to establish the co-located setup, the microservice needs to share the same identity instance:
+Additionally, to establish the co-located setup, the microservice needs to share the same identity instance.
+This is configured in the MTA deployment descriptor (applies to both Java and Node.js):


"applied to both Java and Node.js" should be the default for any shared guide. IMO, only the opposite should be noted.

PDT42 · 2026-06-15T08:58:47Z

 ::: code-group

-```yaml [/srv/srv/main/resources/application.yaml]
+```yaml [mta.yaml]


mta.yaml makes sense to me, reading resources .. but his change still looks suspicious.

PDT42 · 2026-06-15T09:22:51Z

+**2. BTP Destination** - Create a destination in BTP Cockpit with these properties:
+
+| Property | Value |
+|----------|-------|
+| Name | `xflights-ias-app2app` |
+| Type | `HTTP` |
+| URL | `https://<xflights-srv url>` |
+| Proxy Type | `Internet` |
+| Authentication | `OAuth2ClientCredentials` or `OAuth2JWTBearer` |
+| Client ID | Consumer IAS client ID |
+| Client Secret | Consumer IAS client secret |
+| Token Service URL | `https://<IAS tenant>/oauth2/token` |
+| Token Service URL Type | `Dedicated` |
+
+**Additional Property (required for IAS App-2-App):**
+
+| Property | Value |
+|----------|-------|
+| `tokenService.body.resource` | `urn:sap:identity:application:provider:name:data-consumer` |
+
+The key is `tokenService.body.resource` which passes the `resource` parameter to IAS, triggering App-2-App token scoping and adding the `ias_apis` claim.


Why not tell people how they can specify the destination in their mta instead?

EDIT: Justified in **Note:** MTA cannot resolve cross-service credential references like ${generated>xtravels-ias/clientid}. The destination must be created manually in BTP Cockpit or via Destination Service API. - later on. Is that note accurate?

PDT42 · 2026-06-15T09:23:50Z

+**3. Authentication type depends on use case:**
+- **OAuth2ClientCredentials**: For technical user scenarios (no user context)
+- **OAuth2JWTBearer**: For user propagation (requires user token from authorization_code flow)
+
+Both support `tokenService.body.resource` for IAS App-2-App scoping.


Why are these two listed, but none of the other auth types?

PDT42 · 2026-06-15T09:25:55Z

+| Client ID | Consumer IAS client ID |
+| Client Secret | Consumer IAS client secret |


Where do people get these?

PDT42 · 2026-06-15T09:29:46Z

 1. Select **Applications & Resources** > **Applications**. Choose the IAS application of the `xtravels` consumer from the list.
 2. In **Application APIs** select **Dependencies** and click on **Add**.
-3. Type `data-consumer` as dependency name (needs to match property value `ias-dependency-name`) and pick provided API `data-consumer` from the provider IAS application `xflights`.
+3. Type `data-consumer` as dependency name (needs to match property value `ias-dependency-name` in Java, or the dependency name in `tokenService.body.resource` for Node.js) and pick provided API `data-consumer` from the provider IAS application `xflights`.


"... in Java, or the dependency name in tokenService.body.resource for Node.js" - what is the "dependency name"?

PDT42 · 2026-06-15T09:31:19Z

+- **Don't write custom integration logic** for consumed services unless necessary.
+Leverage CAP's remote service architecture when possible to ensure a seamless integration experience.

- **Don't implement connectivity layer code** (for example, to fetch or exchange tokens).
-Instead, rely on the shared connectivity component, which ensures centralized and generic processing of outbound requests.
+- **Don't implement connectivity layer code** (for example, to fetch or exchange tokens) unless necessary.
+Rely on the shared connectivity component, which ensures centralized and generic processing of outbound requests.


IMO these changes just weaken the "Pitfalls" section.

renejeglinsky · 2026-06-15T10:15:03Z

Perhaps this guide should use the Java / Node.js switch, if that is still a thing?

It's not a thing anymore. But code groups that have Java/Node are now remembered by selection without the toggle.

Add Node.js part to Outbound Authentication

4ec8fef

vkozyura requested a review from renejeglinsky as a code owner May 28, 2026 08:27

vkozyura marked this pull request as draft May 28, 2026 08:27

renejeglinsky mentioned this pull request May 28, 2026

Outbound Authentication #2435

Open

vkozyura added 7 commits May 28, 2026 18:09

changes in ias

3696aa2

test and rewrite co-located services

1223b4d

continued

1989b74

sync docs with running tests

f4707e0

small changes

37814e3

use destination

786b0d5

minor

40595d7

vkozyura marked this pull request as ready for review June 5, 2026 13:13

vkozyura and others added 2 commits June 5, 2026 15:13

Merge branch 'main' into outbound-auth-node

600b1ac

remove sdk api part

e5abd9b

PDT42 self-requested a review June 15, 2026 08:39

PDT42 requested changes Jun 15, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Node.js part to Outbound Authentication#2596

Add Node.js part to Outbound Authentication#2596
vkozyura wants to merge 10 commits into
mainfrom
outbound-auth-node

vkozyura commented May 28, 2026

Uh oh!

PDT42 left a comment

Uh oh!

PDT42 Jun 15, 2026

Uh oh!

PDT42 Jun 15, 2026

Uh oh!

PDT42 Jun 15, 2026

Uh oh!

PDT42 Jun 15, 2026

Uh oh!

PDT42 Jun 15, 2026

Uh oh!

PDT42 Jun 15, 2026

Uh oh!

PDT42 Jun 15, 2026

Uh oh!

PDT42 Jun 15, 2026

Uh oh!

PDT42 Jun 15, 2026

Uh oh!

PDT42 Jun 15, 2026

Uh oh!

renejeglinsky commented Jun 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

		\| Client ID \| Consumer IAS client ID \|
		\| Client Secret \| Consumer IAS client secret \|

Conversation

vkozyura commented May 28, 2026

Uh oh!

PDT42 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

renejeglinsky commented Jun 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants