Native mobile apps forced to leak OAuth2 client secret

[hikaritenchi]

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.

1. RFC 8252 and Fitbit's documentation both state that client secrets should not be included in native app code.
2. Fitbit recommends PKCE, which matches RFC 8252, but also still requires the client secret to be used to obtain the token. Step 5 in RFC 8252 Figure 1
3. Since Fitbit's PKCE flow still requires the client secret an attacker can easily obtain that secret through various means (decompiling the app).
4. An attacker with the client secret now has free rein to do all sorts of bad things.

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:

MITREid Connect

IdentityServer3

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.

[hikaritenchi]

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.

[rbsamoht]

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.

[JohnFitbit]

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!

[hikaritenchi]

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.

[JohnFitbit]

@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!

[rbsamoht]

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.