0

I am using this workaround to get the SessionId in my LWC and perform a callout from the JS. I am concerned about if it will pass the security review for managed packages. Have someone used it and can confirm?

Also, if used it in managed package, does it work properly or does it face the error pointed here by lambad in the response comment?

1

No, this would not pass the Security Review, and is inappropriate for a managed package, which should not steal the authentication data of its users. If you want to act on behalf of a user, don't impersonate the user, but ask the user to authorize you to act on their behalf: use an OAuth token with a scope agreed to by the user.

It's pretty easy to setup a connected app and get user authorization, and this has the benefit of giving you a refresh token as well. Now with JWT flows, it's even easier, whereas a session id leaves no audit trail, is effectively sharing auth credentials, and can be done silently without the victim's knowledge or consent. Please don't abuse your users' authentication data this way -- this is private user data that does not belong to a managed package. Rely on your own authentication data and have users authorize you to act on their behalf.

6
  • The problem for this approach is that I need to perform the callout from my LWC javascript. I can not do it in Apex. And I don't know any way to pass the named credential information to the controller. Do you have any suggestion to overcome this? Apr 23 '21 at 8:08
  • Also, so far we are using the same approach but from real VF pages so, what is the difference? That has passed sec reviews so far, and I do not see less risk there or more risk here. Apr 23 '21 at 10:42
  • It would fail the security review in VF or LWC, this is not a specific rule only for LWC. But with lightning there was an attempt to more systematically stop the abuse we were seeing with third party apps grabbing user session ids. For specific advice I would ask what you are trying to do that can't be done with an OAuth token but requires the user's sid. If you can do it with a token, store the token server side and pass it to the client. With JWT, you don't even need to store any tokens, but can mint them on demand and pass them to the client. Apr 23 '21 at 16:03
  • This video might be helpful: youtube.com/watch?v=cViU2-xVscA Apr 23 '21 at 17:37
  • Thank you for your inputs, I will try that way and take a look at the video. Apr 23 '21 at 21:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.