Lifetime Access Tokens for Command Line Tools.

[gr4yweb]

Hi lads,

I am currently working on an small command line tool for fetching my data from your API and pushing it into my graphite carbon server, to build a pretty dashboard in grafana with my fitness data. The API itself is pretty self explainatory but I haven't got that far yet, because I am agonizing with OAuth 2.0 and the "Security" of short lived tokens. I could switch to Implicit Grant Workflow, because that way OAuth 2 is a little less painful, but still has the same problem in common with Authorization Code Grant Workflow.

Both Workflows give a flying duck about command line tools. I don't want to run a server or a web app, I just want to fetch my data every night, which was quite easy with OAuth 1.0a, but OAuth 2.0 completely ignores that category of applications. I have to start an http server, to obtain a token and stop the server when I obtained and saved the token to disk.

I tried all three Application Types and I think the "Personal" application type should allow lifetime access tokens, no matter what Grant Workflow I pick. It took me about 6 hours to figure out the difference of both workflows.

[tonybarry]

Hi gr4yweb,

I am also munching my way through the oAuth 2.0 spec and - like you - don't see a way around having a web presence.  The Implicit Grant Flow (as described by Fitbit) seems to imply that one can get a one-month token (which then expires ...) without using a web presence.  But in my testing, it's still required unless you can get your browser to provide call-backs (and right now I can't do that).

The Authorization Code Grant Flow requires a web presence and that's it.

Like you, I miss the oAuth 1.0 everlasting tokens.  But I doubt Fitbit will bring them back just for us.

Regards,

Tony Barry

[gr4yweb]

---

@tonybarry wrote:

Hi gr4yweb,

I am also munching my way through the oAuth 2.0 spec and - like you - don't see a way around having a web presence.  The Implicit Grant Flow (as described by Fitbit) seems to imply that one can get a one-month token (which then expires ...) without using a web presence.  But in my testing, it's still required unless you can get your browser to provide call-backs (and right now I can't do that).

The Authorization Code Grant Flow requires a web presence and that's it.

Like you, I miss the oAuth 1.0 everlasting tokens.  But I doubt Fitbit will bring them back just for us.

Regards,

Tony Barry

---

Thanks for your Reply. Exactly that was my experience. I use Go as a language and I found a way to stop the server after I retrieved the token, but I still don't like the fact that I have to fetch a new token every 30 days. They documentation provided by FitBit mentions "lifetime access tokens", but never mentions how to obtain said tokens.

I didn't want to blame FitBit at all, because OAuth 2.0 is not their fault. I just wanted to point out that OAuth 2.0 got even worse compared to 1.0 when it comes to covering use cases, even though its the current industry standard. OAuth 1.0 was kinda bearable with the Pin Code workflow, but with OAuth 2.0 that Workflow was removed and was replaced with pure nothingness. Instead everything got even more complex and more "secure", which is more the Java Enterprise Development way of doing things.

Best Regards,

Sascha

[tonybarry]

Hi Sascha,

I have got my Fitbit oAuth 2.0 working now.  And it seems that the Authorisation Code Grant Flow ... kind of ... does not require a continuous web presence .

I use my browser to ask fitbit.com for an authorization code.  They send it off to my web server (which I do have) but really, the redirect URL that Fitbit helpfully put in the web browser is all that's required, as it contains the code.

Then I do the transactions required with the code, get an access token and a refresh token.

The access token works once to get fitbit data.

I then ask for another access token using the refresh token.

I get back a new access token and a new refresh token.

RInse and repeat.

The access token -> refresh token -> access token loop seems to be able to Go On Without A Web Server ...

Now I have just finished my proof of concept code this afternoon.  I may discover some Uglies down the track.  But the Authorization Token Grant Flow might be what you are after.

Regards,

Tony Barry

[JeremiahFitbit · Accepted solution]

I agree that there are things we could do within the OAuth 2.0 framework to make this particular use case easier. We just haven't gotten to it yet.

In the interim, the Authorization Code flow will give you an access token and refresh token. The refresh flow will allow you to have a working access token forever. You don't actually need to run a web server to use the Authorization Code flow, as long as you don't mind a little manual setup to get started.

1. Set your redirect_uri to something non-functional. It doesn't matter as long as it's a valid URL. https://localhost/ is fine.
2. Go to the Authorization page in your browser and authorize your app.
3. You will be redirected somewhere, but all you care about is the 'code' value now appended to your redirect_uri.
4. Make the Access Token request with the provided 'code' value and you'll get your first access token and refresh token. Your script can now make API requests and refresh token requests without running a web server.

[gr4yweb]

---

@JeremiahFitbit wrote:

I agree that there are things we could do within the OAuth 2.0 framework to make this particular use case easier. We just haven't gotten to it yet.

In the interim, the Authorization Code flow will give you an access token and refresh token. The refresh flow will allow you to have a working access token forever. You don't actually need to run a web server to use the Authorization Code flow, as long as you don't mind a little manual setup to get started.

1. Set your redirect_uri to something non-functional. It doesn't matter as long as it's a valid URL. https://localhost/ is fine.
2. Go to the Authorization page in your browser and authorize your app.
3. You will be redirected somewhere, but all you care about is the 'code' value now appended to your redirect_uri.
4. Make the Access Token request with the provided 'code' value and you'll get your first access token and refresh token. Your script can now make API requests and refresh token requests without running a web server.

---

Hi Jeremiah,

Thank you for your reply! 

I still have two questions about request tokens.

1. Does the request token expire together with the access token?
2. I can obtain an access token with an refresh token, like I do with the auth code provided via callback?

[JeremiahFitbit]

---

gr4yweb wrote

Hi Jeremiah,

Thank you for your reply! 

I still have two questions about request tokens.

1. Does the request token expire together with the access token?
2. I can obtain an access token with an refresh token, like I do with the auth code provided via callback?

---

1. The request token will expire immediately upon use. You will get a replacement access token and refresh token when use use the refresh flow.

2. No and this is an intentional part of the OAuth 2.0 framework. The Authorization Code and Refresh flows require use of the client secret. They are considered more secure. Distributed apps can't keep secrets, so this is why the Implicit Grant flow exists. The Implicit Grant access tokens are only long lived to not be irritating to people using your app, since that flow requires user intervention.

[tonybarry]

Hi Jeremiah,

This is very good !  I was wondering if Fitbit actually monitored the fact that the web presence is a functioning server, and from your reply it seems that it does not.

With this information, it would seem that oAuth 2.0 authentication (for Fitbit anyway) is a couple of orders of magnitude easier than oAuth 1.0 ... I have now written elementary authorisation engines for both, and the 2.0 world is much nicer.

The emphasis the docs place on an oAuth 2.0 library would seem to be a bit misplaced.  A colleague and I wrote our oAuth 1.0 authentication engine with much suffering and travail, but this 2.0 version has taken me just seven days, with about four of them being just reading of the docs and hunting around the web chasing examples.

A very big improvement in my view.

Thank you !

Tony Barry

[gr4yweb]

I just wanted to keep you updated about my oauth2 experiments. I just found out that the oauth2 package in Go automatically handles the refresh token flow, as mentioned in this issue on GitHub: https://github.com/golang/oauth2/issues/84#issuecomment-175591180

[CollinChaffin]

So does this answer say that the implicit flow does not work?  No matter what I do with my app set to personal and according to the darn Fitbit API docs the Implicit Grant Flow works with personal - I get a bad request.  In fact, if the only word I change on my initial auth web URL is from "token" back to "code", even with only a one day expire set it works.

So, does the documented implicit grant flow work with an app set to type "personal" and actually provide a token properly, and if so can someone tell me how they are making it work?

Really think Fitbit needs to accelerate fixing these docs and establishing better ground for the dev community.  I literally see posts a year old stating we would have perm tokens and other things implemented long ago.

Any help much appreciated!

Moderator edit: format

[CollinChaffin]

Nevermind, I finally figured it out. Doing the implicit grant flow is so easy. Being by far the easiest to implement, it's amazing the docs simply do not show a decent example of utilizing that method with app type of personal.

Anyway, stay tuned I'm working up my next framework!

 Moderator edit: word choice