skip to Main Content

This question is just informal and thus I cannot provide any sort of MWE/example/…

I thought of developing a Java application to interact with the eBay API.
To do so, one has to obtain a (private) key from them to authenticate to avoid a single application disturbing the normal processes. It’s clear that putting these keys in a Git repository for example and publishing the repo was a bad idea.

On the other hand, I would like to allow others to contribute and/or use my code for their own work (classic open-source approach).

I could think of the following approaches to solve the issue:

  1. Write the main code as a LGPL library and write a small application using the library plus the keys. Thus, the library can be published without problems.
  2. Create a separate class that contains the keys; do not put this into the repository.
  3. Add a text file outside the VCS (or ignored by it) to the project and read it at runtime from the .jar file.
  4. Do some fancy stuff at compile time: somehow replace just before the real compiler runs the correct data into the source files and remove afterwards. That is wrap the compiler in a shell script or configure user defined compilation routines for the critical file.

The benefit of the first two approaches are that it is complicated to regain the key from the completed jar file (I guess, please correct me if it is easily reverse-engineerable). The downside is that any other person will not be able to compile the program. In case 1, the main method is missing; in case 2, a whole class will be referenced but nor be present.

Case 3 is a bad idea because, if you have the jar file, you can directly extract the key as text file and have it in plain text.

Case 4 is, in my own opinion, also not the best solution: messing around with source code at compile time looks quite nasty to me. Nevertheless, it was (as far as I can think of it) the best solution of these presented here.

Can you think of a better solution?
How are such problems handled correctly?

Edit:
To make things clearer:
I am not worried about the credentials of the users that are using my application.
Instead eBay requires that each program using their API authenticates itself with a key.
This way eBay can shut down singe applications if running zombie or doing illegal things (in terms of the license agreement).

These keys (the access keys for the API) need to be readable by the application (otherwise I could not authenticate with them) but these keys must not be available to anybody else.
If anybody had the keys he/she could send API calls in the name of my program and lead to my keys getting revoked.

2

Answers


  1. Store the authentication credentials as environment variables on your production instances.

    Login or Signup to reply.
  2. Don’t give it to them

    There’s a similar question here on security stack exchange which suggests proxying the API calls via your own web services. So instead of distributing the key to clients keep it securely on your server and require clients to be authenticated.

    As soon as you’ve given the API key to the client, whether it’s compiled into your app or downloaded at runtime, they would be able to retrieve it. I wouldn’t have much faith in the key staying a secret if the user was intelligent and determined. Even if you encrypt it like the documentation recommends, at some point in time it has to be unencrypted and sent to eBay in an HTTP request.

    In terms of where to store the keys, if you go with your own services, keep the keys where all your configuration management stuff goes and keep it encrypted. You could have a separate private git repo containing your services ansible configuration. Keep the key in this repo in an encrypted ansible vault file.

    Give each user a different key

    The eBay API doesn’t support this but if you were able to use a different key for each user then at least you’d know who to blame if they the key was abused.

    The API does have the concept of user tokens to let your application act on behalf of the user. However, to use them you still have to pass in your app key on each request. So you’re still left with the problem of where to keep your dev key…

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search