Google OAuth 2.0 Authorization Code (with PKCE) requires a client secret

Question

Google says it supports PKCE for OAuth 2.0 (see docs). However the Google PKCE flow requires a client secret, which is against the PKCE standard and potentially dangerous when the client is a mobile or desktop application, which is what I have.

This appears to be a long-standing issue... see this SO question from 2020.

A few questions:

1. Is it safe to store the client secret on a mobile or desktop client when using the Google PKCE flow? Someone in the SO question linked above suggests it may be:

yes that's the point of PKCE ... the 'client secret' is not considered to be secret. Whether Google forced you to provide one or not, it isn't ultimately trusted.

Another SO answer also suggests this:

it is ok to not keep "client secret" a secret. The type of clients that do not keep confidentiality of client secret is called "public client" in the OAuth2 spec. The possibility of someone malicious being able to get authorization code, and then access token, is prevented by the following facts: (1) Client needs to get authorization code directly from the user, not from the service (2) Redirect URL is registered with client id/secret

A third SO answer suggests "the client secret is much more important for server-side apps than client-side apps".

2. If not, is it safer to use the implicit flow? The top rated answer in the SO question linked above suggests this (but that was back in 2020):

SPAs are still directed to use the implicit flow in Googles' online documentation: https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow).

According to my understanding, the implicit flow has a few major downsides: (1) it does NOT support refresh tokens (see here) which can make for a bad user experience and (2) it has been largely deprecated in favor of PKCE (see here).

3. Any insight into why Google PKCE requires a client secret when it clearly goes against the standard?

Selfjustifying

Answer 1

1. Is it safe to store the client secret on a mobile or desktop client when using the Google PKCE flow?

If the client secret is only used by the client with PKCE, I think keeping the client secret public is not so problematic. To consider PKCE flow, we should consider stolen attack for authorisation_code. Malicious application tries to steal the code after user authentication (e.g. by MITM attack). If we didn't have the code_verifier introduced by PKCE, the malicious user can get a refresh token using the stolen code, client_id and secret. By using the PKCE flow, we can prevent this case with or without client_secret, because the IdP and your application can confirm if the same application requests the refresh_token through code_challenge/code_verifier.

The risk with/without client_secret is the same: a malicious user may be able to reproduce code_verifier from code_challenge.

Any insight into why Google PKCE requires a client secret when it clearly goes against the standard?

Note that client_secret is not generated for Android app. They may consider there are a native client which can store the client_secret securely. Google issues a client_id/secret for every client. They might think that developers can control security.However, I think this puts developers who don't know better at risk of exposing client_secret without PKCE.

Cashman

Answer 2

I managed to find a way to use authorize my app's users with the Google API without having to sneak the client secret into the app. On my Google Cloud Console, I generated a new credential: Create Credentials > Create OAuth client ID I then specified that my app is UWP type (even though it isn't). The credentials Google generated include a client id and a client secret, just as was the case when I had registered my app as Desktop type. However, now when I authorize the user (.NET library Google.Apis.Auth.OAuth2) it doesn't matter if I omit the client secret in my token request or even put in some bogus value for the client secret.

Riordan