Refreshing Tokens with Application Type Client

[lutired]

Hello 🙂

The authorization process works fine (I am using Authorization Code Grant Flow with PKCE and application type is client) and I can also get data correctly. But I just can't figure out how to refresh the tokens with the application type being client.

In the doc website of refreshing tokens https://dev.fitbit.com/build/reference/web-api/authorization/refresh-token/ it states that in the header of the request 'authorization' is required and for value

'Specify the token type and Fitbit user’s access token.
Token type: Basic '.

But it does not work with using 'Basic <access_token>, it gives a 401 with error

'Invalid authorization header format. The client id was not provided in proper format inside Authorization Header. Received authorization header = Basic ...'.

So I looked up that basic token means using the Base64 encoded client_id:client_secret. It would be a lot less confusing if it didn't say 'Specify the token type and Fitbit user’s access token' in the documentation of Refresh Tokens.

The problem here is that I obviously should not use client_secret with application type client. My next idea was to just omit the authorization header.

I looked up that when first retrieving the access and refresh token, it specifies in https://dev.fitbit.com/build/reference/web-api/developer-guide/authorization/ to not have the authorization header when using application type client, but in the detailed documentation of the request https://dev.fitbit.com/build/reference/web-api/authorization/oauth2-token/ it also lists the authorization header as 'required'. But as this request works successfully without the authorization header, I thought the detailed documentation might be wrong again about the authorization header being required for the refresh token call as well as the oauth2 token call.

But turns out this assumption was wrong, because I still get a 401 error with 'Invalid authorization header format. The header was not recognized to be a valid header for any of known implementations or a client_id was not specified in case of a public client Received header = null.'

So, how can I refresh tokens while using application type client?

[Gordon-C]

Hi @lutired 

Are you trying to use the authorization code grant flow with PKCE when the application type = "client"?   

Gordon

[lutired]

Hi Gordon,

yes, exactly. Authorization works fine using authorization code grant flow with PKCE and application type client, I get the first refresh and access tokens. But how can I refresh tokens?

[Gordon-C]

Would you please post the endpoints that you're executing throughout the authorization process and refreshing the first token, including the parameter names and headers?   Please redact any values.   We are working on a tool to help people with this and the tool works for me.   I would like to verify the tool.   And, if there is confusion with how you interpret the documentation, I would like to see if I can fix that too.

[Gordon-C]

Also, I found the documentation error you mentioned "'Specify the token type and Fitbit user’s access token' in the documentation of Refresh Tokens."  I will get that corrected.

[Gordon-C]

One additional comment on this.   My interpretation of RFC 7636 (PKCE standard), PKCE is designed to stop authorization code attacks.   There is nothing that states it stops refresh token attacks.   Therefore, once the exchange of the authorization code has occurred, you'll need to use the Base64 of the client_secret to refresh the token as described in RFC 6749.  They demonstrate the Basic token being used when refreshing the tokens.

If this explanation makes sense, then no need to send the requested information.  I believe ^ will answer your question

[lutired]

Okay, the problem with that is that I am working on an Android App, so it is possible to get the source code. Now if I would use the refresh token call with the Base64 encoded client_id:client_secret, it is possible to easily get the client secret. Isn't that a problem?

[Gordon-C]

Unfortunately, I don't see any alternatives in the PKCE or OAuth2 specification, and we are following the specifications as designed.  Maybe there are Android developers reading this post that can provide some recommendations.