As of August 2020 the best practices document cited is still in draft and being activly updated - head revision here: https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/. Googles' OAuth2 implementation has not yet applied the "work in progress" recomendation of PKCE being applied to web applications. SPAs are still directed to use the implicit flow in Googles' online documentation: https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow).
The standard for PKCE (https://tools.ietf.org/html/rfc7636) details that it was developed as a mitigation for authorisation code interception attacks found on mobile platforms and was originally recommended for implementation by native clients. Google's documentation for "Mobile and Desktop apps" does direct developers to use a PKCE Authorization Code flow. Clients using Google Android, iOS or windows store credential types with PKCE may omit the client_secret (see the note on the refresh token parameter table - and confirmed by Cristiano).
It is now recognised that PKCE eliminates the need for any public clients to store a client secret, and as such can be used to deprecate the implicit flow which always had the flaw of including returned access and identity tokens in a redirect URI. https://developer.okta.com/blog/2019/05/01/is-the-oauth-implicit-flow-dead.
The draft IETF document states in section 2.1.1 that this recognition is likely to become a published standard.
Hopefully Google will update its implementation to remove the requirement for a client_secret for a PKCE token request when the best practices becomes accepted. In the meantime it seems we have no choice but to continue writing SPAs using the implicit flow.
