Checking Scope

[Shalmezad]

Right now, working on porting an app to use OAuth 2. I managed to get a typical case working, but there's a small case bugging me.

When we redirect to fitbit for a user to authorize us to access their data, they're given a page similar to the one below:


So long as all the checkboxes are checked, which is the default, we're fine.
It's when they're not checked that we run into issues.

I was wondering if there's a way to see what scopes the user is allowing the application to access in one call, rather than waiting until a call fails due to a missing permission.

Thanks!

[Shalmezad · Accepted solution]

And within 15 minutes, found it thanks to a somewhat related post here:
https://community.fitbit.com/t5/Web-API/OAuth-migration-and-heart-rate/m-p/866694#M2484

Turns out that when you grab an access token, the scope that the user gave you comes through as well (even though the scope I sent was "profile settings activity", the result is "profile settings"):

{"user_id"=>"######", "expires_in"=>3600, "scope"=>"profile settings", "refresh_token"=>"******************************", "token_type"=>"Bearer", "access_token"=>"******************************"}

[JeremiahFitbit]

Correct. We send the granted `scope` back to you in the redirect_uri when using the Implicit Grant flow and in the Access Token request response for the Authorization Code flow.

[withinhealth]

What did you call to get the token hash?

[withinhealth]

My token comes back with "token", "refresh_token", "expires_at", and "expires", but nothing about scope using Authorization Code Grant flow . Nothing about scope. And if a user didn't check off one of the boxes, it doesn't automatically authorize, it goes back and asks them to approve all scopes instead of remembering it. 

[Durial321]

I'm having the same problem as withinhealth, nothing about scope values in accesstoken response