aarondcoleman
Status of OAuth2 and the token store
Hi,
I am using your great client library in an existing project, that I will need to upgrade soon, in order to be able to keep accessing the Fitbit API, as they are deprecating v1 of the API. What is the status of this client library? :)
It seems that a lot of the endpoints are already implemented (on branch async-portable-auth2implement), and that a design for implementing a token store has been proposed on branch async-portable-auth2-tokenstore - is that correct? I am not completely sure on what branch to go from?
I have a service running in the background on my server, that is handling the synchronisation of data from Fitbit to my system. I already save tokens, but it seems like the token store solution would be the way to go - especially now that I have to update my own implementation to handle refresh tokens. How would I go about extending and implementing the proposal you already have - any things I should keep in mind, or have you already implemented this elsewhere?
I am sorry if I'm asking about things that is documented elsewhere, but the structure of this project is not totally clear to me. I look forward to hear from you with some guidance.
I'm sort of in the same boat, I'm not sure which branch to go off of, since there appears to be 3 different ones. Also, when looking at the async-portable branch, the SampleDesktop project seems to still be pointing at the original oauth url's, so I'm thinking that only the SampleWebMVCOAuth2 is actually up to date?
Any little shove in the right direction would be appreciated, as the library has worked great for us up to this point, and I just need to get this update implemented with our next dev cycle.
Thanks a bunch!
Hi @h8red @lassebn yeah, we're a little lagging on this. We need to get you guidance on how to proceed.
My hangup right now is that I'm watching another thread on Fitbit's dev channel here regarding the expired OAuth Token and refresh: https://community.fitbit.com/t5/Web-API/Refresh-token-amp-network-timeout/m-p/1109618/highlight/false#M4203
OAuth 2.0 adds the extra requirement of handling refresh tokens and constantly swapping out your local auth token per user before they expire. We had previously decided that, if you implemented the required interface for a token store we set up, the library would do a behind-the-scenes token swap and store for you, reducing your complexity. I'm concerned though now that I'm seeing a rare, but likely scenario of a network miss (a timeout or something of the like) where Fitbit's servers think they've provided a new refreshed token but it's never received.
I'm not sure what we at Fitabase are going to do to mitigate this, but it's likely some other background worker process that has as much robust network handling as possible so if we don't stick the landing, we don't get locked out of accounts previously authed.
So, we may restructure the OAuth 2.0 bits to remove the token refresh piece and leave that up to your code to catch / try and make sure you're supplying already refreshed auth instead.
Might try to get a little more guidance from @JeremiahLee and update this group shortly. That said, MOST of the bits are in the async-portable branch and I did a status update a few months ago as a video here: https://www.youtube.com/watch?v=ggx-4SwuYm4
For sure we're migrating to an async, PCL based method structure so you can start moving over to that using your OAuth 1.0 keys and start changing surrounding code now, which we've been doing ourselves at Fitabase.
--Aaron
Hi @aarondcoleman, thank you for your quick reply!
I have also been stumped by this added complexity with the refresh tokens, and Fitbit not supporting long living tokens - though they may in the future?
I think it is fair to let the user of this library handle the token refreshing. Of course I was hoping that this library would implement the token store, and handle this so I wouldn't have to :)
But I will get started on moving to the async library. Very nice with the video walkthrough.
You say you would like some guidance on how to proceed - that kind of feedback can I give?
//Lasse
Thanks very much for the response. I've been sick the past few days, and realized I never replied, I probably read the email and then fell back asleep. I'll dig into that video and get things rolling.
I've done similar such things for refreshing tokens, so hopefully this will fall in line with the same theory as those and it'll go smooth.
Again, thanks for sharing and keeping us in the loop.
~Brian
On Wed, Jan 13, 2016 at 6:18 AM, Lasse Benn Nørregaard < [email protected]> wrote:
Hi @aarondcoleman https://github.com/aarondcoleman, thank you for your quick reply!
I have also been stumped by this added complexity with the refresh tokens, and Fitbit not supporting long living tokens - though they may in the future https://community.fitbit.com/t5/Web-API/Non-expiring-OAuth-2-0-tokens/m-p/821763#M2271 ?
I think it is fair to let the user of this library handle the token refreshing. Of course I was hoping that this library would implement the token store, and handle this so I wouldn't have to :)
But I will get started on moving to the async library. Very nice with the video walkthrough.
You say you would like some guidance on how to proceed - that kind of feedback can I give?
//Lasse
— Reply to this email directly or view it on GitHub https://github.com/aarondcoleman/Fitbit.NET/issues/54#issuecomment-171303299 .
@lassebn all feedback welcome. I don't think Fitbit is ever going to make OAuth 2.0 tokens long lived like 1.0, that would defeat the purpose (security). What they are likely going to do is allow an old token pair (token + refresh) to overlap in case a network issue or local DB issue fails midway through a refresh operation.
We're talking about how to give Fitbit.NET consumers the flexibility to user something like ITokenStore, or not, just let them manage tokens outside the library. In our case for Fitabase, we will probably utilize an outside process to manage refreshing tokens to make sure we don't lose a response object midway which another dev already encountered using HttpClient here: https://community.fitbit.com/t5/Web-API/Refresh-token-amp-network-timeout/m-p/1102761/highlight/true#M4142
Mitigating this issue is now a burden on the consumer, which is unfortunate. They may allow a 2 minute window to retry your best, or get locked out if you can't get a refresh to complete, so we need to make sure the library can be configured for users who want a "do your best, re-prompt if we get locked out" approach, vs others who want a "go nuclear with retries in the next 2mins if you fail because we can't re-prompt a user".
I figured it may come down to something like that, it'll add a decent amount of complexity client side, trying to refresh the token or asking for credentials again, but I don't think there is a real elegant solution or a "nice" way around that. Thanks a bunch for the feedback.
On Fri, Jan 22, 2016 at 11:45 AM, Aaron Coleman [email protected] wrote:
@lassebn https://github.com/lassebn all feedback welcome. I don't think Fitbit is ever going to make OAuth 2.0 tokens long lived like 1.0, that would defeat the purpose (security). What they are likely going to do is allow an old token pair (token + refresh) to overlap in case a network issue or local DB issue fails midway through a refresh operation.
We're talking about how to give Fitbit.NET consumers the flexibility to user something like ITokenStore, or not, just let them manage tokens outside the library. In our case for Fitabase, we will probably utilize an outside process to manage refreshing tokens to make sure we don't lose a response object midway which another dev already encountered using HttpClient here: https://community.fitbit.com/t5/Web-API/Refresh-token-amp-network-timeout/m-p/1102761/highlight/true#M4142
Mitigating this issue is now a burden on the consumer, which is unfortunate. They may allow a 2 minute window to retry your best, or get locked out if you can't get a refresh to complete, so we need to make sure the library can be configured for users who want a "do your best, re-prompt if we get locked out" approach, vs others who want a "go nuclear with retries in the next 2mins if you fail because we can't re-prompt a user".
— Reply to this email directly or view it on GitHub https://github.com/aarondcoleman/Fitbit.NET/issues/54#issuecomment-174024263 .
@aarondcoleman That makes sense. And I don't think I can provide any more feedback at the moment. But thanks for your feedback. Should I close this issue thread?
I'm satisfied, if that means anything. On Jan 23, 2016 11:00 AM, "Lasse Benn Nørregaard" [email protected] wrote:
@aarondcoleman https://github.com/aarondcoleman That makes sense. And I don't think I can provide any more feedback at the moment. But thanks for your feedback. Should I close this issue thread?
— Reply to this email directly or view it on GitHub https://github.com/aarondcoleman/Fitbit.NET/issues/54#issuecomment-174212580 .
After talking with Aaron it sounds like the whole refresh token story is being reviewed and looked at by Fitbit so once they've told us we'll assess and work out a solution. Might be worth closing this item until that point. Cheers
