Difference between revisions of "An Idea for Handling API Keys"

From F-Droid
Jump to: navigation, search
m
m
 
Line 13: Line 13:
 
To resolve the need for API keys, but the inability to bundle with an app, the developers of Client X and Client Y do the following.
 
To resolve the need for API keys, but the inability to bundle with an app, the developers of Client X and Client Y do the following.
  
1) User installs Client X
+
# User installs Client X
2) Client X asks user to install an "API Manager" app.
+
# Client X asks user to install an "API Manager" app.
3) Client X then sends a URL to API Manager whereby the user can sign up for their own personal API key (e.g. "https://free-service-x.net/get-api-key")
+
# Client X then sends a URL to API Manager whereby the user can sign up for their own personal API key (e.g. "https://free-service-x.net/get-api-key")
4) Client X can then subsequently ask API Manager for the API key for Service X when required.
+
# Client X can then subsequently ask API Manager for the API key for Service X when required.
  
 
The API Manager app can:
 
The API Manager app can:

Latest revision as of 10:49, 16 February 2016

There are a few people who have asked about how to handle free software that depends on API keys. Lets start with two assumptions:

Although often API keys are indicative that the webservice you are using is proprietary, this is not always the case. For example, imagine a hosted version of a free software web app. The people hosting it may wish to rate-limit the way in which requests are sent to that web service, while perhaps self hosted versions would not require such a limitation.

API keys should not be published. Not with source code, not in compiled binaries, not in any way. If they are released with a .apk (even in binary form) then they are able to be decompiled and recovered. This opens the door for abuse whereby people gain access to the API key for a particular app and end up blacklisting that app from being able to talk to a specific webservice. Having said this, compiling in API keys into an apk seems to be the norm with proprietary software.

Now that those two assumptions are out of the way, lets get into the proposal:

Lets use the case of "Free Web Service X" and "Free Web Service Y". Each are hosted versions of a free software web app, and each requires a different API key to access.

There are two different free software Android clients, "Free Android Client X" and "Free Android Client Y". They want access to service X and Y respectively. F-Droid does want to encourage people to publish API keys. Also, they don't want to compile software that depends on the API keys.

To resolve the need for API keys, but the inability to bundle with an app, the developers of Client X and Client Y do the following.

  1. User installs Client X
  2. Client X asks user to install an "API Manager" app.
  3. Client X then sends a URL to API Manager whereby the user can sign up for their own personal API key (e.g. "https://free-service-x.net/get-api-key")
  4. Client X can then subsequently ask API Manager for the API key for Service X when required.

The API Manager app can:

  • Be completely free software, will not be distributed with any secret keys.
  • Either act as a stand alone application, or perhaps more appropriately it can interact with the Android Accounts API.
  • Specify different formats of API keys so that various clients can request different types of key. Perhaps at the time Client X sends a URL to the API manager, it can also specify some metadata about the format of the API key. For example, some API keys are a single token. Others (e.g. OAuth2.0) might be a public token and a private shared secret.