Google's OAuth 2.0 for installed apps and Client Secret not being a secret

Question

It appears that Google has been modernizing OAuth interactions for native apps as announced initially here https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html

and as evidenced by their current documentation pages https://developers.google.com/identity/protocols/OAuth2InstalledApp

I have been able to run the sample console app in the referenced github repo successfully.

This flow exchanges the authorization code for an access token using the client secret among other parameters. However, it is well known (and as stated in the referenced article) client secrets cannot be securely stored in installed apps. The same article states this fact in the following way

The process results in a client ID and, in some cases, a client secret, which you embed in the source code of your application. (In this context, the client secret is obviously not treated as a secret.)

So if this flow is the recommended flow for installed app, should we just not worry about protecting the client_secret and embed it right in the app? If so, what about this flow makes it so?

Also, as the sample shows, a random http redirect url is generated locally which is not registered anywhere in Google Developer Console's Credentials page. This is unlike Azure AD where you have to be specific about the redirect uri when registering a native app.

Answer 1

The behavior of Google's authorization server is gated on the type of client you register.

It's an oddity that the "client secret" is required for Desktop and TV clients, but not iOS and Android, however for all 4 native app types, the server treats the clients as non-confidential, and the "client secret" value is effectively an extension of the client id. This is in contrast to web-clients, where it is assumed the client secret confidentiality is maintained, and thus they can be treated differently for actions like incremental auth.

Regarding the registration of redirect URIs, this is also gated on client types. For some types like Web, manual registration is required. For other types like Desktop, the redirect URI is pre-registered (in the case of desktop, http://127.0.0.1:*/*).