Cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

OAuth 2.0, Authentication Methods and mobile apps

Hello everyone, it's my first post here. Please be gentle.

 

Had some time laid up due to ill health and been planning a mobile App to gamify/incentivize some Fitbit data (I do love my Surge). Been reading through the forums and the documentation, have a clear plan in my head, some good looking mockups and I've just rented a testbed VPN with SSL and a domain.

 

I just hope someone here with some experience of fitbit could sanity check my plan. Before I get too deep in the dev.

 

Let's assume this is running on iOS for the sake of argument.

 

1. User installs and starts my App.

 

2. After some preamble the app directs them to the Fitbit provided authentication page.

 

3. They login, give permission for the basic activity data (all I need) and Fitbit with it's return page directs that browser to my callback URL.

 

4. Now I'm going to have a large server component so I'm using the authorization code grant flow and that callback URL is a special page on my webserver with SSL.

 

5. That webpage then prompts my web server to exchange the code for an access token and refresh token. While it's there it also gets the Fitbit user id I've seen mentioned in the API.

 

6. It saves these on it's database and associates them with the Fitbit user (using a salted hash of the fit bit user id, no personally identifiable user information will be on the database)

 

7. My webservers return page to the mobile browser does a second redirect to a specially configured URL which kickstarts my app and gives it the information it needs to continue (I've seen documentation about doing this both in iOS and Android).

 

 

8. My app can then periodically ask my webserver if any further data is available for the user, at which point it will connect, possibly renew its access with the refresh token, and return the requested updates.

 

9. End result, the user should hopefully never have to provide permission again because I have a refresh token and the secret key is only on my webserver not in my client app. Everybody happy.

 

Does that seem sensible?

 

I haven't done much with OAUTH2 and I'm slightly worried point (5) may fail because the "code for token" exchange is being done from a completely different IP address than was used earlier in the process.

 

Also I've never worked with Fitbit before and although point (6) doesn't seem to violate any Ts&Cs (indeed it seems pretty essential for a wholly web based service) I would like to check it's not a no-no.

 

Many thanks in advance for any help.

 

 

Best Answer
0 Votes
1 REPLY 1

Hey Andy,

 

How did you get on with implementing this based on your plan? I'm looking to implement pushing activity data from my mobile apps (iOS & Android) to Fitbit. The plan you had sounded sensible to me and was similar to the way I was planning to do the authentication and authorisation in iOS and Android. Wanted to check in with you just in case things had changed since creating this post.

 

Thanks in advance

Alex

 

 

Best Answer
0 Votes