Most web applications that are currently being built or already exist usually rely on at least one 3rd party API if not dozens. A 3rd party API is something that a web application uses to gain access to another web application’s and / or company’s services. For the remainder of this post an ‘API’ will be assumed to be a 3rd party API. This means it belongs to another web application and / or company and not the web application using the API.
These APIs serve as bridges to connect a given web application to a respective service that Facebook or Google or Twitter (among others) provides and controls. Data travels back and forth on these bridges between a given web application and a respective service. In some cases these services will incur costs for the web application using them. There are also certain situations where using an API to gain access to a service may be completely free as long as the usage of the API is within a certain quota that the company providing the service defines.
To gain access to these APIs some APIs require you to only use an API key and others may require you to use API key, API ID, API token, or some other identifier. The amount of fields that an API chooses to use to authenticate other web applications with their services is up to the API provider. In most cases it’s usually API ID and API key, sort of like email and password when users need to authenticate with basic web applications, like email or social media platforms.
A common question that is asked is what is the most professional and secure way to store API credentials (ID’s, keys, tokens, hashes, etc.)
There have been many discussions throughout the years about best practices on how to store API credentials. Most professional web application developers agree that storing API credentials in the database or in the code or code repository is a security issue (and generally speaking, a no-no). Many professional web application developers agree that storing API credentials at the OS level is preferable and is one of the more secure ways to do it. The rest of this post will walk you through how to store API credentials on a production level Linux / UNIX OS box using environment variables.
Technical: This part assumes that your production deployment OS is Linux / UNIX based and that you have administrative access to the user accounts and files associated with deployment of the web application you will be working with (a little knowledge of the terminal is also required).
What follows is an example of how to update your .bashrc file to account for the environment variables you’re going to add to enable access to 3rd party APIs:
Bash Terminal Guide:
Open the .bashrc file of the user in the OS that is associated with the deployment of the web app
Add the following to the bottom of the .bashrc file (be sure to repeat for as many API credentials as you need)
export SOME_API_ID = "api_id" # make sure to include the quotes export SOME_API_KEY = "top_secret_api_key" # make sure to include the quotes
After entering all of your API credentials as environment variables in the .bashrc file, save it and exit the text editor. From the terminal prompt, run the following to register the new environment variables in the OS
if everything has gone correctly then executing
api_id: command not found
Which is the value we stored in the .bashrc file (similar results should happen when referencing $SOME_API_KEY)
Next is an example of accessing environment variables in a Ruby (and by extension Ruby on Rails) environment:
# Ruby on Rails console Example $ 2.2.3 :001 > ENV['SOME_API_ID'] => "api_id" $ 2.2.3 :002 > ENV[‘SOME_API_KEY’’] => "top_secret_api_key"
In different web application frameworks the OS environment variables are accessed differently, but with Ruby on Rails it’s as easy as writing “ENV[‘SOME_API_ID’]” anywhere in the codebase that this code can be executed.
Fun Fact: Type “env” into the terminal prompt to see a list of existing environment variables.