Is Default Browser Necessary for Hybrid Apps with Web Part as Salesforce

[SohamSFDCDev]

Hi Fitbit Developer Support and the Community,

We are facing a great trouble in fetching important information in the call back URL using default browsers for oAuth 2.0 and then moving back to a custom url scheme.It is the way the app is packaged which wont allow or barely allows this. Ours is a Hybrid app where the Web Part is on Salesforce.com - a super secure cloud application governed by credentials maintained by the renowned Cloud Based SAAS/IAAS/PAAS provider. In fact that is the only way our app users can login to the app - by loging in with Salesforce and then we redirect them to the native part of the app.

Is it still UNAVOIDABLE to move to default browsers and NOT webview from the native part of the app. And moreover the document specifies instructions for Native and web applications. What about hybrids where the web part is secured by a Fortune 500 company like Salesforce.com

Please please help us - we are facing a lot of challenges and breaking our back, neck and head without being able to do meaningful development.

One more question - does this apply to oAuth 1.0a as well? 

Please reply asap.

[JeremiahFitbit]

Can you please describe each step of the authorization flow and where each screen/interaction is taking place?

---

@SohamSFDCDev wrote:

Ours is a Hybrid app where the Web Part is on Salesforce.com - a super secure cloud application governed by credentials maintained by the renowned Cloud Based SAAS/IAAS/PAAS provider.

What about hybrids where the web part is secured by a Fortune 500 company like Salesforce.com

---

Salesforce.com is a solid product, but that is not the point of the security requirement.

Fitbit requires the authorization page to appear in the system browser to prevent applications from keylogging, phishing, or executing UI redress. Without reviewing the source code of every application, use of the system browser is the only way Fitbit can trust that third-party native apps are not intercepting account authorizations. The system browser also provides people security features to know they're authenticating with the real Fitbit.com, such as being able to inspect the TLS certificate and use password managers.

---

@SohamSFDCDev wrote:

Please please help us - we are facing a lot of challenges and breaking our back, neck and head without being able to do meaningful development.

---

I think this is a reasonable requirement that other apps have been able to comply with. I know that you're eager to work on your app, but implementing security best practices is meaningful development. 🙂

---

@SohamSFDCDev wrote:

One more question - does this apply to oAuth 1.0a as well? 

---

OAuth 1.0a is deprecated and should not be used.

[SohamSFDCDev]

Hi Jeremiah,

Thank you so much for your reply. The steps are:

1) A to be user of the app registers with us with the help of a webform - which provides us with the Email and DOB of the user to be stored in our SOA DB. An  instruction is sent to the user to download the app from the play/app store.

2) After the download - the user registers with the previously shared EMAIL and DOB - any duplicates are 

     rejected by our SOA DB. After successful registration the users provide the app with a username and password (encrypted) which is passed to Salesforce.com's Site.createPortalUser('username', 'password', 'Portal Account') [through webservice to our salesforce application's  endpoint if the app is being used OR through the the backend controller of the desktop version of the app which is written on Salesforce itself]

   So the Username and Password is stored with Salesforce and the Application Owners/Keepers have 

   no access to it as per the Quality and Service policy of SFDC.

3) The user is then moved to the Login Screen which is again on SFDC and uses the Salesforce Site.login
('username','password') method which is again a SFDC internal system code and we do not have any control over it.

4) After logging in the user is prompted to choose Fitbit as a device of choice. After a small pop up which reminds the user to check all boxes on the authorization page we redirect the user to the authorization page.

5) The user allows us access to get Read-Only data and depending on the streams of data which the user has given us access to (we need activities,sleep,body,device and profile as mandatory streams) we either show them a sync confirmed or sync failed. 

ALL THIS IS DONE IN SFDC.

Only after the Sync Confirm page we are using a deep linking to move to the native part of the app and by then, with the help of your API we could fetch the necessary data to show on our app's dashboard and also have subscribed the user to all the four stream's for real time data syncs.

That's it. 

We have a target of moving to oAuth 2.0 asap and our native app vendor partner might take some more time to find out a way to move this to the default browsers and hand over the packaged app. 

Also the older versions of the app will continue to work on webview I feel.

Can we please have an extension to this implementation too now that we know that oAuth 1.0a deprecation has moved to August. 

We have mutiple regions to support and have already moved over the users to oAuth 2.0 and the Salesforce code to authorize, authenticate and data sync with Fitbit and our App is ready and tested.

Please advise. Can we have a small call with your API support team to get whitelisted or something please

or atleast get an extension (after moving the oAuth 2.0 code) to make the native app work with default browsers.

Please reply.

[JeremiahFitbit]

---

SohamSFDCDev wrote:

ALL THIS IS DONE IN SFDC.

Only after the Sync Confirm page we are using a deep linking to move to the native part of the app and by then, with the help of your API we could fetch the necessary data to show on our app's dashboard and also have subscribed the user to all the four stream's for real time data syncs.

That's it.  

---

By "IN SFDC", do you mean the user is in a browser on salesforce.com? If so, I'm confused why there is a problem.

---

@SohamSFDCDev wrote:

We have a target of moving to oAuth 2.0 asap and our native app vendor partner might take some more time to find out a way to move this to the default browsers and hand over the packaged app. 

Also the older versions of the app will continue to work on webview I feel.

Can we please have an extension to this implementation too now that we know that oAuth 1.0a deprecation has moved to August. 

We have mutiple regions to support and have already moved over the users to oAuth 2.0 and the Salesforce code to authorize, authenticate and data sync with Fitbit and our App is ready and tested.

Please advise. Can we have a small call with your API support team to get whitelisted or something please

or atleast get an extension (after moving the oAuth 2.0 code) to make the native app work with default browsers.

---

Can you please contact us privately to discuss an extension to this requirement?

[SohamSFDC]

Hi Jeremiah, sorry for the delay in replying to your comment. Thank you so much for keeping this thread alive. 

By "IN SFDC" I meant - a website (web part of a Hybrid App) built on the Force.com Platform (Salesforce's Platform As A Service) which requires login credentials governed by Salesforce.com viewed by the registered users in Webview on a mobile device.

Again, thank you so so much for guiding me the Private Consultancy link. I have appraised the application manager on the same and he will get in touch with you/your team asap. We are having an internal discussion on this and will contact you asap.

In the meantime can you please reply what you feel about "IN SFDC" now? Is it still a problem as per Fitbit view?

Thanks much!