CODEWITHSUNDEEP
oauth-2.0fitbit
pradeepa
pradeepa

Reputation: 4164

How to identify application user after Fitbit authorisation

Suppose a user with user id 100 in our application database starts OAuth 2.0 authorisation with Fitbit using endpoint http://localhost/api/100/fitbit/authorize, gets authorised by callback http://localhost/api/fitbit/callback.

How can we identify which user got authorised, so that we can store the access token and refresh token? The callback URL can not contain the user id 100 since Fitbit configuration does not allow extra parameters in the redirect URL.

Or is there any other way to identify the authorised user?

Upvotes: 0

Views: 111

Answers (1)

mbj
mbj

Reputation: 1015

There seems to be a bit of misunderstanding regarding how OAuth 2.0 works.

In your question, you use the word callback, as if the Fitbit servers are going to make an HTTP request to that URL, but that's not how it works. What happens is that the user agent, where the Fitbit authorization page was displayed, receives a HTTP 302 Found response with a Location header containing the redirection URI. So it's a response rather than a callback, and it instructs the user agent to load the URI specified in the Location header (and if the user agent is a browser, it will).

Normally, you would set redirect_uri to a page within your application, where your user is already logged in, so that you can identify the user id from the session data (just like you would for any other page in your application)

If, for some reason, the above doesn't work for you, then you can use the state query parameter when redirecting the user to Fitbit's OAuth 2.0 Authorization page. Fitbit's "Using OAuth 2.0" documentation describes the state parameter as follows:

Provides any state that might be useful to your application when the user is redirected back to your application. This parameter will be added to the redirect URI exactly as your application specifies.

The state parameter is a standard feature of OAuth 2.0, so this isn't Fitbit specific. It can be used with any service that implements OAuth 2.0 correctly according to RFC 6749.

Upvotes: 0

Related Questions