Callback using query parameters instead of fragments

[tsauvajon]

Hello,

I've had some trouble setting up OAuth because of how the callback URL is formed.

Here's the example URL in the OAuth tutorial: https://localhost/#_=_scope=nutrition&user_id=28GVHZ&token_type=Bearer&expires_in=593433&access_token=blablaTokencopy

It uses a fragment identifier (following the # symbol) instead of query parameters (following the ? symbol).

The fragments are supposed to refer to a section heading or a specific HTML element in a page, while the query is, usually, a list of key / value pairs.

Appart from the confusing URL, it causes some problems: I am, for example, building an application using AWS API Gateway + AWS Lambda. The API Gateway doesn't forward the fragments (why would they ?) nor the full URL, but it forwards the query parameters: it would be really easier if it was following the convention.

I will probably find a workaround but I don't think it will be clean; it would also be better for new developers to have an URL formed with a `?` instead of a `#`.

My question is: do you plan on changing the `#` to a `?`, or do you have a specific reason to using the `#` ?

EDIT: Apparently web browsers don't pass the fragment identifier at all to the servers. We have use the front-end as a proxy to change the request from a # to a ? if we want a back-end to handle the callback.

[Gordon-C · Accepted solution]

Hi @tsauvajon,

We follow the RFC6749 specification for our authorization process.  For Implicit Grant Flow (which I'm assuming you're using), the specification states in section 4.2, page 32, bullet (C) and section 4.2.2, "Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the redirection URI provided earlier. The redirection URI includes the access token in the URI fragment."

If you prefer to have the access token returned within a query parameter, take a look at our documentation for Authorization Code Grant Flow or Authorization Code Grant Flow with PKCE.  In this scenario, we will return the authorization code as a query parameter.  In your application configuration at dev.fitbit.com, you'll need to change your OAuth 2.0 Application Type from "client" to "server".  For "personal" applications, we use the Implicit Grant Flow.

Gordon