0

I have a customer who is looking to launch an existing iOS app from within SF1, passing enough data to be able to pull/push data from/to Salesforce via API calls. I am basing the solution on using the url so we could have a link in SF1 to load something like: myapp://?sessionId={sessionId}&SFInstance={Partner_Server_URL}

My question: Is there a better solution than passing values in the url? I know they could be encoded/signed to provide a level of security and I'm looking to not require the user to log in to SF from inside the iOS app as I know about them already from inside the SF1 app.

Thanks in advance.

Improve this question

1 Answer 1

Reset to default
1

What you're describing is basically a session hijacking attack, using a session ID from one app (SF1) to create a session in another app. I am doubtful whether this is technically possible — even if you did get the session ID from SF1, it is likely tied to SF1's OAuth client ID. And if it is possible, it is a surefire way to bait Salesforce security into globally revoking the OAuth client ID for your partner app, and then you're in a really bad spot.

Moreover, you said:

I'm looking to not require the user to log in to SF from inside the iOS app as I know about them already from inside the SF1 app.

Respectfully, this is not your call to make. You cannot assume that a user who has granted access to one app (SF1) would want her credentials used, without her knowledge or consent, to authenticate another app. Even if the second app were a first-party Salesforce app, and even if you had the user's consent, you can imagine the security and access control implications of additional apps hijacking credentials in this manner.

The instance/partner server URL, however, is definitely fine to share with a partner app, and it'd surely be a big improvement to the partner app experience if your user no longer needs to type in their server URL.

Improve this answer
3
  • Thanks for you response - a few interesting points there. I was basing my suggestion of using sesionids from the conga app whereby these values allow an external system to grab data from SF seamlessly from a button click of VF page. SF have inbuilt session hijacking controls and so there would be limitations but I believe this could be a viable solution. Also, as part of the setup process I could gain the users permission to use their credentials, and allow them to revoke permissions at any time; as well as setup security endpoints and connected app settings as necessary to allow access.
    – Richard Durrant
    Commented Mar 27, 2015 at 10:49
  • I don't think it works that way. I am also doubtful the Conga app is hijacking sessions in the way you claim. If you want your user to be able to revoke permissions, you need your own connected app and your own session ID and your user needs to complete the OAuth flow in your app.
    – Jonathan Hersh
    Commented Mar 27, 2015 at 16:27
  • I'm not claiming they hijack sessions, I believe they use it for identification purposes in conjunction with OAuth to make server level API calls. If you google conga and sessionId then you'll come across how they format button javascript and formulas to include sessionid and serverurl. I will investigate further and post any useful findings.
    – Richard Durrant
    Commented Mar 27, 2015 at 17:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .