Add Node.js part to Outbound Authentication#2596
Conversation
PDT42
left a comment
PDT42
left a comment
There was a problem hiding this comment.
Perhaps this guide should use the Java / Node.js switch, if that is still a thing? The examples and required steps seem pretty disconnected.
| ::: 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. | ||
|
|
||
| ::: |
There was a problem hiding this comment.
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.
|
|
||
| ::: 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. |
There was a problem hiding this comment.
In the updated structure, this jump back to Java systemUser is very disconnected. What is the / Is there an equivalent in Node.js?
|
|
||
| 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): |
There was a problem hiding this comment.
"applied to both Java and Node.js" should be the default for any shared guide. IMO, only the opposite should be noted.
| **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. |
There was a problem hiding this comment.
Why are these two listed, but none of the other auth types?
| | Client ID | Consumer IAS client ID | | ||
| | Client Secret | Consumer IAS client secret | |
There was a problem hiding this comment.
Conceptually, should the destination be using the creds from the service binding or a dedicated service key?
It's not a thing anymore. But code groups that have Java/Node are now remembered by selection without the toggle. |
| service-plan: lite | ||
| ``` | ||
|
|
||
| **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. |
There was a problem hiding this comment.
Perhaps: Move this to the beginning of "2. BTP Destination" or right before "Client ID and Client Secret are obtained from the consumer's ..."? Provide the reason for what should be done, before doing it?
PDT42
left a comment
PDT42
left a comment
There was a problem hiding this comment.
I am still having trouble with the structure: I think intermixing the Java and Node.js guides like this doesn't provide much benefit and is at least a bit confusing ... However, the documented process (without trying to go through it myself) makes sense to me.
3 participants
No description provided.