feat: IAS App-To-App Auth by davidkna-sap · Pull Request #6185 · SAP/cloud-sdk-js

davidkna-sap · 2025-12-02T14:28:22Z

Handles SAP/ai-sdk-js-backlog#347.

marikaner

now I finally got through. Big PR => Many comments. Good work 😄

marikaner · 2026-01-21T08:59:42Z

+    return options?.jwt?.app_tid;
+  }
+
+  requestAs satisfies never;


[q] What is the purpose of this line?

It should type-check that all possible values of requestAs are handled before reaching else.

Ah, I see. Thanks!

marikaner · 2026-01-21T09:16:58Z

+   */
+  app_tid?: string;
+  /**
+   * IAS tokens don't have scope property.


[q] Should it then be something like never or undefined?

I wanted to stay compatible with the existing ClientCredentialsResponse, but considered that something of a breaking change (also XSUAA will likely always have this).

marikaner · 2026-01-21T09:22:18Z

+  let urn = `urn:sap:identity:application:provider:clientid:${resource.providerClientId}`;
+  if (resource.providerTenantId) {
+    urn += `:apptid:${resource.providerTenantId}`;
+  }
+  return urn;


When I see let I get the urge to remove it. Not sure this is better though. Just an idea. Feel free to keep your version.

Suggested change

let urn = `urn:sap:identity:application:provider:clientid:${resource.providerClientId}`;

if (resource.providerTenantId) {

urn += `:apptid:${resource.providerTenantId}`;

}

return urn;

const resourceUrn = [resource.provderClientId, resource.providerTenantId].filter(val=>val).join(':apptid');

return `urn:sap:identity:application:provider:clientid:${resourceUrn}`;

I changed it with a slightly different approach.

marikaner · 2026-01-21T09:24:22Z

+ * @returns A promise resolving to the client credentials response.
+ * @internal
+ */
+async function getIasClientCredentialsTokenImpl(


[req] Every function is an implementation of something. The name currently sounds like we get some implementation. I assume this is not what is meant. Can we just remove the Impl?

I think the name is fine getIasClientCredentialsToken is the inner implementation of getIasClientCredentialsToken which iirc calls it with additional resilience.

KavithaSiva

Could you please also add tests for getDestinationFromServiceBinding with the authentication type Oauth2JwtBearer.

Currently, only this method supports this authentication type, transformServiceBindingToDestination always creates a destination with Oauth2ClientCredentials. Could you also please confirm if the transform function for other services also always create a Oauth2ClientCredentials destination?

KavithaSiva · 2026-01-23T07:40:25Z

+    );
+  }
+
+  return buildIasDestination(response.access_token, service, options);


[req] I checked the flow again here and when iasOptions.authenticationType is set to OAuth2JWTBearer, the built IasDestination is still always one with OAuth2ClientCredentials which is incorrect as we do the access token retrieval using the jwt bearer token flow.

So, the authentication type OAuth2JWTBearer should be retained.

I've addressed this by allowing authenticationType overrides for buildClientCredentials, and forwarding it in buildIasDestination.

davidkna-sap · 2026-01-23T08:36:20Z

Only xfS4hanaCloudBindingToDestination uses BasicAuthentication instead of a client credentials.

Should I also forward the refresh token to the destination object if available? This would mean extending DestinationAuthToken. I did not do this right now because with the current flow (App-to-App), refresh tokens should always opted-out of, and they wouldn't be used.

I've also noticed that none of the Destinations with client-credentials set clientId or clientSecret, I avoided changing this to avoid further extending the scope of this PR.

KavithaSiva · 2026-01-23T09:28:55Z

Should I also forward the refresh token to the destination object if available? This would mean extending DestinationAuthToken. I did not do this right now because with the current flow (App-to-App), refresh tokens should always opted-out of, and they wouldn't be used.

I didn't understand this fully, in which API do you want to do this? Where is the refresh token available?

davidkna-sap · 2026-01-23T09:37:23Z

Should I also forward the refresh token to the destination object if available? This would mean extending DestinationAuthToken. I did not do this right now because with the current flow (App-to-App), refresh tokens should always opted-out of, and they wouldn't be used.

I didn't understand this fully, in which API do you want to do this? Where is the refresh token available?

IdentityService.fetchJwtBearerToken may return a refresh token if refresh_expiry is not 0, which we do if either App-to-App is used (performance - unless the user opts) or if we have an app_tid (from the token or elsewhere which should always be the case).

I think the best place to put refresh tokens would be DestinationAuthToken, because they are tied to the main token.

KavithaSiva · 2026-01-23T13:06:23Z

I've also noticed that none of the Destinations with client-credentials set clientId or clientSecret, I avoided changing this to avoid further extending the scope of this PR.

I think that's fine because the Destination object is also used to represent destinations we create in CF, and these may have clientId and clientSecret depending on the Auth type.

Here we are creating destinations by transforming a service binding, I am not sure if they really add any value if set.

KavithaSiva · 2026-01-23T13:09:13Z

IdentityService.fetchJwtBearerToken may return a refresh token if refresh_expiry is not 0, which we do if either App-to-App is used (performance - unless the user opts) or if we have an app_tid (from the token or elsewhere which should always be the case).

I think the best place to put refresh tokens would be DestinationAuthToken, because they are tied to the main token.

Understood, let's do this in the next IAS follow-up ticket, which may need and use the refresh token.

KavithaSiva

One last round of minor comments to address and then it's good to go.
Code looks much cleaner and readable now, thanks for all the effort and good work.

KavithaSiva

LGTM, let's go!

as discussed

davidkna-sap and others added 4 commits December 1, 2025 16:28

wip

90a2f9a

support reading user_uuid from jwtPayload

b2d80f4

add extraParams option field

0ed94aa

Changes from lint:fix

5ec4657

davidkna-sap changed the title ~~feat: IAS App-To-App Auth~~ feat: [DO NOT MERGE] IAS App-To-App Auth Dec 2, 2025

davidkna-sap added the don't merge Don't merge label Dec 2, 2025

add workaround

a541e18

davidkna-sap force-pushed the davidkna-sap_poc-ias branch from c0cc0e8 to a541e18 Compare December 4, 2025 15:00

davidkna-sap added 5 commits December 4, 2025 16:14

chore: add targetURL option to iasBindingToDestination

24cd0a7

chore: fix clientsecret auth

1348182

rename options & forward mtls creds to destination

2f2cbf6

chore: add changeset

f9ce3a5

chore: update changeset msg

9990c6f

davidkna-sap commented Dec 8, 2025

View reviewed changes

Comment thread packages/connectivity/src/scp-cf/jwt/jwt.ts Outdated

davidkna-sap commented Dec 8, 2025

View reviewed changes

Comment thread packages/connectivity/src/scp-cf/identity-service.ts Outdated

davidkna-sap and others added 6 commits December 9, 2025 11:52

chore: print warning if both mtls and mtlsKeyPair provided

a146af2

Merge branch 'main' into davidkna-sap_poc-ias

6ab8a1f

move ias-specific opts to iasOptions & refactor parameter handling

e5e67eb

increase resource name flexibility

cd8e736

chore: try to fix lint error

34b83be

support user-token exchange

fdb3d35

davidkna-sap force-pushed the davidkna-sap_poc-ias branch from 0165671 to fdb3d35 Compare December 12, 2025 14:07

davidkna-sap added 2 commits December 12, 2025 15:11

add experimental to changelog note

af1d0bd

add initial cache implementation

62d4023

davidkna-sap commented Dec 15, 2025

View reviewed changes

Comment thread packages/connectivity/src/scp-cf/destination/destination-from-vcap.ts Outdated

davidkna-sap added 3 commits December 15, 2025 11:10

harmonize towards AuthenticationType and allow disabling cache

437fd87

harmonize ias/xsuaa caching

de930e4

use xssec as the base implementation

fbcca4b

github-advanced-security AI found potential problems Dec 16, 2025

View reviewed changes

Comment thread packages/connectivity/src/scp-cf/jwt/jwt.ts Fixed

Comment thread packages/connectivity/src/scp-cf/jwt/jwt.ts Fixed

make codeql happy

e71c268

Merge branch 'main' into davidkna-sap_poc-ias

77f8fce

marikaner previously requested changes Jan 21, 2026

View reviewed changes

address review comments

f786e98

davidkna-sap requested a review from KavithaSiva January 21, 2026 12:32

davidkna-sap and others added 3 commits January 21, 2026 14:06

minor fixes

39f9c1e

Merge branch 'main' into davidkna-sap_poc-ias

698556a

Merge branch 'main' into davidkna-sap_poc-ias

9fe2b0f

KavithaSiva requested changes Jan 23, 2026

View reviewed changes

davidkna-sap added 2 commits January 23, 2026 09:15

address review comments

4e21754

add additional unit tests for OAuth2JWTBearer

d349c6e

davidkna-sap requested a review from KavithaSiva January 23, 2026 08:38

KavithaSiva reviewed Jan 23, 2026

View reviewed changes

address review comments

2ee6a9e

davidkna-sap requested a review from KavithaSiva January 23, 2026 13:41

KavithaSiva approved these changes Jan 23, 2026

View reviewed changes

davidkna-sap and others added 3 commits January 23, 2026 15:19

remove @experimental from getIasToken

d339122

changeset: remove (experimental)

5712f98

Merge branch 'main' into davidkna-sap_poc-ias

cde01f8

davidkna-sap requested a review from marikaner January 26, 2026 11:31

davidkna-sap enabled auto-merge (squash) January 26, 2026 11:32

davidkna-sap disabled auto-merge January 26, 2026 11:32

davidkna-sap enabled auto-merge (squash) January 26, 2026 11:32

davidkna-sap merged commit d444438 into main Jan 27, 2026
26 checks passed

davidkna-sap deleted the davidkna-sap_poc-ias branch January 27, 2026 10:08

Conversation

davidkna-sap commented Dec 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

marikaner left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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!

Uh oh!

Uh oh!

KavithaSiva 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!

Uh oh!

davidkna-sap commented Jan 23, 2026

Uh oh!

KavithaSiva commented Jan 23, 2026

Uh oh!

davidkna-sap commented Jan 23, 2026

Uh oh!

KavithaSiva commented Jan 23, 2026

Uh oh!

KavithaSiva commented Jan 23, 2026

Uh oh!

KavithaSiva left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

KavithaSiva left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

davidkna-sap commented Dec 2, 2025 •

edited

Loading