Store session variables in CAP Node JS application

[carlonnheim]

Hi,

Is there a suitable way to store session context variables for a user in a CAP NodeJS application? We have a scenario requiring connectivity with an external application which does not support principal propagation and are considering an approach where we authenticate the user through an oAuth flow in the CAP application. We need a safe way of storing the users authentication token.

Any input on how to store session variables as well as on the approach overall regarding the authentication is much appreciated.

Thanks!

//Carl

[gregorw]

Can you share what's the external application? What types of authentication does it support?

[carlonnheim]

Hi,

It supports oAuth authorization_code grants. I.e. we redirect the browser to the authorization server with our CAP application (or rather the managed approuter we have in front of it) as the redirect uri. When we get the response back it has a code, which we can exchange for the user token with the auth server.

This part works fine, but it is not clear to me where to keep the token (and refresh token) in a safe way and connected to the users session. The approuter does this for us (when we have the xsuaa etc. involved), but I do not see how I can do it when those are not in play (the only thing I can configure on the external application is creating an app, getting a client ID and Secret and setting the redirect uri.

Thanks for your support!

//Carl

[gregorw]

Is the external app also providing the user authentication or do you still use XSUAA?

[carlonnheim]

Hi,

Yes, it does.

We hit the target application’s https://…/oauth2/authorize from our CAP backend which gives us a redirect to it’s connected authentication server.

Once the authentication is complete we get a call back to the CAP backend with a code which we then exchange for tokens through the applications https://…/oauth2/token endpoint.

The XSUAA is not involved. It would of course be preferred since we are authenticating the same user, but the external app does not support that. This is why we are trying this workaround - the user has to trigger this authorization flow by visiting a specific url on our app to start the above process.

We have it working up to the point where we have the access token and refresh token on-hand. I need a suitable and secure way to associate it with the user’s session so I can use it in upcoming api calls, just like the app router does when the XSUAA is involved. Would be absolute best if I could offload the whole problem to the approuter (the flow is in essence the same but the XSUAA is replaced with something else, so it should have the basic features required), but I cannot find a way to configure it like that.

Thanks!

//Carl