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

Implicit token times get reset to 1 day

ANSWERED

Ok, first off - dealing with Implicit Grant Flow, not Authorization Code, so please don't say "go do this in Authorization Code" - we're not there yet.  

 

My problem:  Writing an iOS app, logging into FitBit to access data.  I can make an initial login, and get an expires_in return value of 30 days or a year (for example), and get a valid token, etc.  However, if, for example, I remove my app from the simulator, and reinstall, I'm forced to log back into Fitbit (which is expected), and when I do so, the response from the server has expires_in at some value less than 86400 (the amount is the time in seconds since I made the original request).  

 

This shortened expires_in value is seeminly confirmed by users losing access a day after making their initial login. 

 

So which is wrong - the documentation, which states that we can have expires_in values greater than 86400 (1 day) or the back end which is capping the expires_in value for the token at 86400 regardless of what we ask?

 

Thanks for any help you can provide.

 

(And yes, we are looking into Authorization Code flow, but I need to get this up and running quick, so this is my route for now).  

Best Answer
0 Votes
1 BEST ANSWER

Accepted Solutions

@Gilthalas 

EDIT:

Users will get a new token every time they go through the flow, but they won't be prompted to authorize until the first authorization has expired. Even though a new token is issued after the second flow, the expires_in value is still counting down from the initial authorization.

 

We initially tested with expires_in set to 1 day (so what we saw was expected behavior), but we're not able to reproduce the exact behavior you're seeing.

 

Seems like the initial authorizations for your users are being set to 1 day.

Andrew | Community Moderator, Fitbit

What motivates you?

View best answer in original post

Best Answer
0 Votes
6 REPLIES 6

@Gilthalas I was able to reproduce what you're seeing. We'll look into this.

Andrew | Community Moderator, Fitbit

What motivates you?

Best Answer
0 Votes

Thank you so much!!!  Looking forward to your response.

Best Answer
0 Votes

Hi - just wanted to check in and see if there had been any update on this?  Thanks!

Best Answer
0 Votes

@Gilthalas 

EDIT:

Users will get a new token every time they go through the flow, but they won't be prompted to authorize until the first authorization has expired. Even though a new token is issued after the second flow, the expires_in value is still counting down from the initial authorization.

 

We initially tested with expires_in set to 1 day (so what we saw was expected behavior), but we're not able to reproduce the exact behavior you're seeing.

 

Seems like the initial authorizations for your users are being set to 1 day.

Andrew | Community Moderator, Fitbit

What motivates you?

Best Answer
0 Votes

But that's where I'm confused - in my initial request, I'm asking for a expires_in value of > 1 day (e.g. 30 days).  The response contains that requested value, but it still expires in less than a day.  

 

So why is the backend returning a token that expires in a day, although it initially reports it as a 30 day token (or whatever I originally requested it as)

Best Answer
0 Votes

OK I can report that now it IS working as I would expect it to - I asked for a year token.  When I went to go grab that token, the expires_in seems to be 1 year - TimeSinceIAskedForTheToken, which is what I expect.  

 

I'll keep an eye on it and let you know if I have problems again.

Best Answer
0 Votes