PKCE and client_secret

[remiwaw]

Hello,

Why it is required to put a client_secret in a request header when using PKCE? I thought the whole point of PKCE is NOT to use client_secret?

https://dev.fitbit.com/build/reference/web-api/oauth2/

Authorization Header

The Authorization header must be set to Basic followed by a space, then the Base64 encoded string of your application's client id and secret concatenated with a colon. For example, the Base64 encoded string, Y2xpZW50X2lkOmNsaWVudCBzZWNyZXQ=, is decoded as "client_id:client secret".

POST https://api.fitbit.com/oauth2/token
Authorization: Basic Y2xpZW50X2lkOmNsaWVudCBzZWNyZXQ=
Content-Type: application/x-www-form-urlencoded

client_id=22942C&grant_type=authorization_code&redirect_uri=http%3A%2F%2Fexample.com%2Ffitbit_auth&code=1234567890&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

[GordonFitbit · Accepted solution]

Hi @remiwaw.   Great question!

PKCE doesn’t replace the Authorization Code Grant Flow.  PKCE is an extension to the authorization flow which provides added security when verifying and authorizing the client / server connection.  You’ll still follow the Authorization Code Grant Flow process to obtain the authorization code and access token.  Authorization Code Grant Flow does require using the client_secret as you pointed out. 

When using the parameters introduced in the PKCE standard, the additional verification step will be followed within the existing authorization request to obtain the access token.

[remiwaw]

According to Oauth documentation, when used in native apps client-secret shouldn't be hardcoded within apps:

 Secrets that are statically included as part of an app distributed to
   multiple users should not be treated as confidential secrets, as one
   user may inspect their copy and learn the shared secret.  For this
   reason, and those stated in Section 5.3.1 of [RFC6819], it is NOT
   RECOMMENDED for authorization servers to require client
   authentication of public native apps clients using a shared secret,
   as this serves little value beyond client identification which is
   already provided by the "client_id" request parameter.

https://tools.ietf.org/html/draft-ietf-oauth-native-apps-12#section-8.5 

As you mentioned the server still requires this code for authentication:

Authorization Code Grant Flow does require using the client_secret as you pointed out. 

So how we can safely store client-secret within app? 

[GordonFitbit]

With a couple of searches, I found a couple of web pages that explain how to store your secret.  Here are some links you can review.  I'm sure there are other ideas for you to consider

https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/

https://stackoverflow.com/questions/28609526/store-client-secret-securely

I would like to highlight one important comment in the RFC (https://tools.ietf.org/html/rfc8252#section-8.5😞

Authorization servers that still require a statically included shared secret 
for native app clients MUST treat the client as a public client (as 
defined by Section 2.1 of OAuth 2.0 [RFC6749]), and not accept the secret 
as proof of the client's identity.  Without additional measures, such 
clients are subject to client impersonation (see Section 8.6).

[MunkiiYebee]

@GordonFitbit we are currently looking at reviewing our use of secrets and certificates throughout our app. The fact we have our client_secret in the native app is a concern. We are currently using Authorization Code Grant Flow.

The way I read your replies you are saying that even with PKCE you still need to send the "client_secret". Am I understanding you correctly? I ask this because we just tried using PKCE with Postman against the Fitbit API and we did not need to send a client_secret.

Thanks

[GordonFitbit]

Hi @MunkiiYebee 

Yes.  With PKCE you will still need to use your client secret in the Basic token to initiate the authorization flow.  I'm curious how you were able to use PKCE within Postman and not need a client_secret.   Would you be able to record a video and PM it to me?

[MunkiiYebee]

I'll send the video over now

[GordonFitbit]

@MunkiiYebee 

A correction to my previous reply.   PKCE does not require using the client secret to initiate the authorization flow.   Instead, the code_challenge and code_verifier will be used to authenticate the application with Fitbit and define user consent with application.   Your application type should be set to "client" instead of "server".   

We will clarify this information in the documentation.

[damianmehers]

Hi Gordon,

In order to exchange the authorization code receiving using the PKCE flow into a token, I need to make an Access Token Request, which requires the setting of an `Authorization` header composed of a Base64 encoded string of my application's client id and secret concatenated with a colon.

This means I need to embed the client secret in my app, which is not what I want to do.  I thought the whole point of the PKCE flow was to provide a way for apps to authenticate without embedding a secret in the app.

Am I misunderstanding something?

Damian

UPDATE:

Despite the documentation indicating it is required, the authorization header is not required when translating the code to a token during PKCE

[hugeh0ge]

Hi damianmehers,

I have the same opinion as you, and I solved the same issue with your UPDATE comment. 

Thank you!

And I think definitely this behavior(of not needing authorization headers) should be written in the document to assure that client_secret is not needed at all when using PKCE.