2

I was writing a bash script for Gmail that would authorize itself using OAuth2, and make API calls using the received tokens. It worked.
But now I'm stuck on thinking how to securely store the Client ID and Client Secret in my script, which is open to all on GitHub. Since leaking one's own Client Secret and Client ID isn't a good idea, as someone else will be easily able to disguise their apps with one's own. How do I proceed with this issue?

Here's the issue in short:

  • My program critically needs Client ID and Client Secret to work.
  • My program is open source and hence I can't include them directly in the code.
  • I want all the users who download my program to be able to work with my own set of Client ID and Client Secret, without them actually knowing what the Client ID and Client Secret are!

Basically, I need to think of a way that would transfer some secret data, either through or bypassing GitHub, from my end to the user's PC such that only the program(my script) must be able to read it, not the user!

I know this seems impossible, but I posted this question to verify if it's possible or not. If possible, then I'd like to know how.

Community
  • 1
Utkarsh Verma
  • 279
  • 3
  • 18
  • 1
    it is unclear what you are asking ............... are you asking if you can have multiple applications using the same ClientID and ClientSecret? – jsotola Jan 21 '19 at 03:06
  • please edit your question to include that requirement .... then delete the comment – jsotola Jan 21 '19 at 16:32
  • Are you trying to keep the secret out of the published code on github (where the entire world can see it), or are you attempting to hide it from the user? The first is possible (by putting it in a user config file that's not on github); the second is not (because the script, run by that user, needs to be able to read it). – JigglyNaga Jan 22 '19 at 12:42
  • @JigglyNaga I'm trying to do both, that is, I want the secret to be available to all the clones(from GitHub) but the user mustn't be able to access or see it. Something like encrypting the secret on GitHub, and decrypting it back on the user's PC without his/her knowledge. Also, I tried to include everything in my question and I don't quite get what else to add more to clarify it. Please guide me. – Utkarsh Verma Jan 22 '19 at 14:19
  • If the (encoded) secret, and the script that includes steps to decrypt it, are both on a public github, then everyone can retrieve the secret and decrypt it. The pushback you're getting is not so much "unclear what you're asking" as "How would that ever work? Have you thought this through?" If the question were reopened, then I would only expect an answer "No, that's impossible", with a longer explanation why. – JigglyNaga Jan 22 '19 at 17:18
  • I did know it was impossible, but I just asked here for workarounds or alternatives. – Utkarsh Verma Jan 23 '19 at 00:06
  • @JigglyNaga I have improved the question a bit more. Please see if the hold can be lifted. – Utkarsh Verma Jan 24 '19 at 00:31
  • Thankyou for expanding. It looks like you want the whole world to be able to see how many unread emails there are in *your* Gmail inbox (not their own), while not being able to read them. Have I understood that correctly? – JigglyNaga Jan 24 '19 at 11:23
  • @JigglyNaga You've misunderstood my app, it's for all users, not only for my email. My script is just *a bash application which outputs the number of unread emails in one's Gmail account*, not preferably mine. What it does is, *make an initial OAuth authorization request to Google*, once authorized with the user's account, it then generates an API access token(account specific) using **the app's Client ID and secret**. The API access token is later used *to make API calls to access the unread email count of the authorized account*. – Utkarsh Verma Jan 24 '19 at 16:05
  • The app, run by lots of users, needs a Client ID, but not a client secret. See [What prevents another app from stealing my Google OAuth client ID?](https://stackoverflow.com/questions/53622075/what-prevents-another-app-from-stealing-my-google-oauth-client-id). – JigglyNaga Jan 24 '19 at 16:24
  • @JigglyNaga Since the generated tokens(which don't require Client secret) are short-lived, my application which makes requests every 30 minutes, has to [refresh the API token](https://developers.google.com/identity/protocols/OAuth2InstalledApp#exchange-authorization-code), which requires the client secret. I'm following the steps in my script as stated in the docs, therefore you can clearly see why my app needs to have the Client Secret and Client ID, since my app refreshes the token before each API call. – Utkarsh Verma Jan 25 '19 at 02:51

1 Answers1

2

No; you would need a cloud/server component/proxy to add the secret to each request (regardless of the programming language).

Of course people do try hiding a local copy, but it never works out for them.

Proxy example:

client> curl my.server.com/list/1
server> curl api.mail.google.com/list/1?key=123

so your proxy just passes all parameters/headers/data and adds your ID and Secret to the request. That may lead to a lot of bandwidth on your server so you should consider adding an option to use ones own Secret with no proxy for heavy users.

user1133275
  • 5,488
  • 1
  • 19
  • 37
  • Do you have an idea on how to do that? – Utkarsh Verma Jan 21 '19 at 07:09
  • The proxy part. – Utkarsh Verma Jan 21 '19 at 23:48
  • How would it make a difference if it's still accessible through a curl request by anyone? I might have understood it wrong, but to me, the above example implies that the secret and client ID are to be fetched through a server request(which anyone can make) therefore it's still accessible to everyone and hence the secret's out! – Utkarsh Verma Jan 24 '19 at 16:11
  • Ah, I think I've got it. So basically my script will first make a request to my own server for creating an access token(because my own server has the client secret). Once the token has been generated, it will be returned to the script. Is that correct? – Utkarsh Verma Jan 25 '19 at 02:55
  • If that were the case, then I don't think I'll be able to implement it since I don't own a server or a domain. – Utkarsh Verma Jan 25 '19 at 02:56