Support iss and userJwt Combination

[FrankEssenberger]

Relates to this public issue or this BLI

In their project @ww917352 they are doing the following:

• They have a refresh token
• They transform it to a JWT with user information using some stored client credentials - they could also use the destination service with OAuth2RefereshToken for that but this would mean one more call. So they do it directly
• Then they use this token to fetch a desination `executeHttpRequest({destinationName:'theirDest',jwt:'obtainedUserJwt'})
• However, they receive an error from the @sap/xssec library:

Jwt token with audience: [ 'uaa', 'sb-xsuaa!b30841' ] is not issued for these clientIds: [\n 'sb-uaa-action-runtime-service-xsappname!b43524',\n 'uaa-action-runtime-service-xsappname!b43524'\n].

This error comes from the fact, that we always try to get a service token for the given JWT. This was also an issue in the issue mentioned above. If they do the following:

• Get a client credentials grant token for the bound destination service (we call this provider service token in SDK code)
• Make a call to the destination service with
  • X-user-token header their user token
  • authorization the provider service token
• they get the destination with auth tokens exchanged as expected.

My initial idea to solve this issue would be the following:

• We implement the lazy token loading as mentioned in the issue above.
• The selectionStrategy: alwaysProvider on the executeHttpRequest({destinationName:'therDest', jwt:'ibtainedUserJwt', selectionStrategy: alwaysProvider})

There could also be the option that we allow to specify some headers directly in the fetch options of the destination. Then you could even combine with the iss property so you get a service token for some tenant and provide the usertoken manually to have full flexibility:

executeHttpRequest({destinationName:'therDest', iss:'ibtainedUserJwt', 'X-user-header': somevalue})

[FrankEssenberger]

I thought about it a bit and currently we ignore the the iss options if the jwt is given in addition. However, we could allow to combine these such as:

• iss -> determines the service token (no validation via xssec library)
• jwt -> determines the X-user-tenant if the token flow requires it.

@ww917352 what do you think?

[ww917352]

Yes, that is what I tried to suggest in our meeting. If both are provided, there is no need to fetch a service token from the user token, because it can be fetched using iss. In this case, we can get service token using iss, and set the user token jwt as the X-user-token header.

[FrankEssenberger]

Change to the code:

• Remove the distinction between token type iss and xsuaa keep only xsuaa with the user token to be optional.

interface XsuaaToken {
  type: 'xsuaa';
  userJwt?: JwtPair;
  serviceJwt: JwtPair;
}

• If the jwt is not given and the flow requires a user (PrincipalPropagation or OAuth2XYZ with user dependent) we fail if the JWT is not set. This is ok, but it would be nice to also add a warning if the userJWT is present but does not contain user information print a good warning message. Only print the warning for user dependent auth flows. Consider fields like user_id, email... to hold the user information.
• Change the creation flow for the XSUAA token here:
  • Case1: iss and jwt is given: Use iss to create the subscriberServiceToken and keeup the jwt as subscriberUserToken (will later be used as X-user-tenant)
  • Case2: jwt is given: Try to use JWT to create a service token - note that this will become lazy later so that onlyProvider will be a way to avoid this but for this ticket just create the service token on the spot.
  • Case3: iss is given: Create a subscriberServiceToken and the jwt stays undefined. If the authentication flow needs a user Jwt later on it will fail as before.
  • Add test for the combined iss and jwt case here There is one test that it ignores iss if jwtif provided. This is of course not valid anymore.

[ww917352]

@FrankEssenberger

Hi Frank,

Any update on the plan to support this in V3? We are already using V3 now.

Thank you!

Cheers,
Wei

[FrankEssenberger]

The team has this on the agenda. Best Frank

[marikaner]

The last PR to fix this was just merged. Now you should be able to use both iss and jwt in a manner that iss identifies the tenant when fetching destinations and jwt identifies the user (without validation). We will release a new productive version within this week, feel free try the canary version before to make sure it works as you expect it.