8

A client_secret.json file is used in the OAuth 2.0 authorization flow for the Google Drive API (example).

If I include client_secret.json in my Java application, access the JAR contents is extremely easy. So, should I worry? I have no way to make this file "secret".

What wrong can be done with this information? A final user has to grant access to my application in order to access his Google Drive files.

Update: It seems that two cases can be analyized.

  • What can be done only with client_secret.json?

This was the intention of my first question. The only thing I can think of is that if a user links his account to my app it can exhaust my Free quota for the Drive API (1,000,000,000 requests/day).

  • Someone access stored credentials for a user (StoredCredential file, in the example) plus client_secret.json.

I guess this is the worst case, since that "someone" can act as my app in the user account.

Update 2: Google docs can be found here: Using OAuth 2.0 for Installed Applications

The client ID and client secret obtained from the Developers Console are embedded in the source code of your application. In this context, the client secret is obviously not treated as a secret.

Improve this question
2
  • I am no security expert so I'm just going to try my best here but if I was an attacker here is what I would do: as malware on the client's machine, open the jar, read the client_secret.json, and use your credentials to now allow me access into the drive account that your user thought he was only granting permission to your app. Since I'm not particularly familiar with Drive's API or the connection process for it, take my example with a grain of salt (heh) unless someone confirms it as a viable threat.
    – d0nut
    CommentedNov 5, 2015 at 17:39
  • @iismathwizard I updated the question to consider your example
    – IvanRF
    CommentedNov 5, 2015 at 18:03

1 Answer 1

Reset to default
4

You should not include the client secret in a javascript/desktop/mobile application

The reason is, like you said, it's very easy to access. You cannot protect it if you embedded it into your application. Once an attacker find your client secret, he can now impersonate your client. The client secret is only meant to be included on web servers.

Use OAuth2 Implicit Flow

OAuth2 Implicit Flow was designed specially to solve that problem. In the implicit flow, there is no client secret and once a user authenticate with OAuth2 provider, the client will receive the access token directly hence no need for a client secret.

https://www.rfc-editor.org/rfc/rfc6749#section-1.3.2

Do not use Implicit Flow for Authentication

OAuth2 was built for authorization which is not the same as authentication. If you need authentication, you will need to look at Open ID Connect which is built on top of OAuth2 to provide all the missing parts needed for secure authentication.

About security

While it's recommended to use the Implicit Flow when using a javascript/desktop/mobile client, it's mostly for convenience to reduce the number of rounds trip required. Since you cannot protect the client secret, there is no reason to include it.

The one disadvantage of removing the client secret (and the extra step linked to it) is that the client cannot know anymore if the token was issued for him since tokens are not bound to a specific client. This leads to multiple opportunity for phishing attacks like described here :

https://www.rfc-editor.org/rfc/rfc6749#section-10.16

Improve this answer

    You must log in to answer this question.

    Start asking to get answers

    Find the answer to your question by asking.

    Ask question

    Explore related questions

    See similar questions with these tags.