Search code examples
c#oauthgoogle-oauth

Is it good practice to declare authorization credentials in plain text?


Is it good practice to declare GCP application authorization credentials, i.e. Client ID and Client Secret in plain text?

I've been working on a Windows desktop app with C#, which involves uploading a file to Google Drive. My real concern is that when I've got to publish the app, the application's Client ID/Client Secret shall be disclosed, as I've stored them as variables in the app. Is it safe? Or is there any other, better way to store them in your app while authorizing it with GCP?


Solution

  • To be clear we are talking about application credentials created on Google cloud console (client id and client secret) and not user credentials (refresh token, access token) which are created when the user consents to an applications access to their data.

    If you check googles TOS you will notice that it states.

    Subject: Changes to the Google APIs Terms of Service

    Asking developers to make reasonable efforts to keep their private keys private and not embed them in open source projects.

    This also applies to desktop applications. You should not include for example a settings file in your application which a user could open in clear text and see your client id and client secrets. It should be compiled into your application (yes the app could be decompiled and the use could get them that way) or better yet stored on your server so that your application can then request it as needed. This however is not optimal if your application is designed to work offline as well.

    Google is aware that there is a gray area with regards to credentials being compiled into applications. It is considered to be an acceptable risk. (I had a conversation with the Oauth team a number of years ago about this)

    why you should protect your credentials.

    The main issue is that if someone does get your client id and client secret they can then use it and google has no way of knowing its not you. To make matters worse neither do the users of the app. So if they start spamming or leaking data its your app that will be to blame and you.