09-09-2019 19:34
09-09-2019 19:34
I spent quite a few hours trying to understand PKCE and client secrets, and I think I've finally understood it to the point where I would like to propose a change, or understand why certain security decisions were made.
Previous questions have tried to raise this concern, but the response was to "store your secret securely", which goes against point #1.
One linked resource even explicitly mentions for servers (in this case, Fitbit) to not give a mobile app a client secret at all.
If the developer is creating a “public” app (a mobile or single-page app), then you should not issue a client_secret to the app at all. This is the only way to ensure the developer won’t accidentally include it in their application. If it doesn’t exist, it can’t be leaked!
A few other projects also have this issue, and people have raised GitHub issues:
Finally, Okta has a good article about this that also drives home this point:
Instead of shipping a client_secret in a mobile app, the way PKCE works is the app creates a new random secret every time it starts the OAuth flow.
09-09-2019 19:39
09-09-2019 19:39
I pressed post before I was finished, but the point of my post was to request Fitbit to remove the client secret requirement to obtain tokens when using PKCE. It's unnecessary, and reduces security for all Fitbit Applications that have native apps.
Alternatively, a 4th option for OAuth 2.0 Application Type of "native app" that doesn't generate a client secret at all.
10-02-2020 12:29
10-02-2020 12:29
I agree with hikaritenchi on that point. I think Fitbit should provide an alternative to the Implicit Grant.
Implicit grant is not recommended according to https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#page-6
In order to avoid these issues, clients SHOULD NOT use the implicit grant (response type "token") or other response types issuing access tokens in the authorization response, unless access token injection in the authorization response is prevented and the aforementioned token leakage vectors are mitigated.
10-12-2020 14:27
10-12-2020 14:27
Hi @hikaritenchi,
An alternative to the Implicit Grant Flow is the Authorization Code Grant Flow. We typically recommend this flow over the Implicit Grant Flow as it is a more secure connection. I believe this was also discussed in a recent thread, which you can read more about here: https://community.fitbit.com/t5/Web-API-Development/PKCE-and-client-secret/m-p/2807797#M9294
I hope this helps!
10-12-2020 23:46 - edited 10-12-2020 23:47
10-12-2020 23:46 - edited 10-12-2020 23:47
Hi @JohnFitbit,
Thanks for the reply! I believe you might have intended to reply to rbsamoht instead of me, as I mention using PKCE, which is only available with the Authorization Code Grant Flow.
That thread that you linked is exactly the same thread that I linked in my original post and unfortunately also doesn't address the issue, which is that the PKCE flow should not require the client secret. It's mentioned in that thread that the PKCE flow is an extension to the normal Authorization Code Grant Flow, which requires a client secret, but PKCE was designed to remove the client secret requirement.
10-14-2020 15:02
10-14-2020 15:02
@hikaritenchi, Thanks for clarifying. We're actually discussing this with our team and hope to get an update soon.
It's likely that the update will be posted in the other thread within the next few days. Let me know if you have any additional questions in the meantime!
11-06-2020 12:16 - edited 11-06-2020 12:22
11-06-2020 12:16 - edited 11-06-2020 12:22
Hi @JohnFitbit, it wasn’t clear in my previous message but I was also referring to Authorization Code Grant Flow with PKCE. As @hikaritenchi pointed out, PKCE flow should not require the client_secret at all.
I just tested it and I am able to retrieve the authorization code but I can’t get a access token since the Access Token Request REST endpoint (https://api.fitbit.com/oauth2/token) requires a Authorization header that contains a client_secret.
As mentioned in your post (https://community.fitbit.com/t5/Web-API-Development/PKCE-and-client-secret/m-p/4535209/highlight/tru...) the initialization of the authorization flow does not require the client_secret, but the next step (Access Token Request) requires it.
In the specific case where Authorization Code Grant Flow with PKCE replaces the Implicit Grant Flow, a full authorization path that doesn't require a client_secret at all should be provided. The code_verifier would be used as a "replacement" for the Authorization header.