REST APIs and Application Security

Transcript of the free preview lesson. Remaining lessons unlock with the full course.

Hello, my name is Josh Guardino and in these lessons, you will learn about REST API security. Let's begin by exploring API keys and access management. There are several ways to secure a REST API. Although some REST APIs are open and can be accessed by anyone, the vast majority of REST APIs have some sort of security to govern the authentication and possibly the authorization for clients of the API. One popular pattern is to use API keys. An API key is simply a randomly generated system ID with a corresponding password but the ID is called an API key and the password is normally called a secret. API providers that support API keys will provide a mechanism by which someone can request an API key. This request form might be available to the general public through something like data.gov, the US government's data clearing house but often for paid services, API keys can only be requested by registered and paying customers. API key signup forms provide a great opportunity to collect a variety of information about how the key will be used, how to contact the owners of the key and any other type of registration information that is deemed necessary by the owners of the API. As an example, let's look at the very popular Spotify for Developers API. After having registered for an account, I can create an app which would be a client of the API and this app is automatically granted a client ID or API key and a client secret, which is like a password. Many times when API keys are first assigned, the secret is only shown once. If the secret is lost, the key will need to be regenerated. However, Spotify allows for rotation of the secret without having to change the client ID or API key. With the API key, a client of the Spotify API can then create a request to receive an access token through a process called OAuth. In the Department of Motor Vehicles API, I have added an authentication check to all API endpoints that expects an API key and secret to be passed in the request headers. And it is standard to use the x-api-key and secret header names to store these values. To the v1/drivers post endpoint, let's add x-api-key and x-api-secret headers and we'll set them both to a value of test which should cause the request to fail authorization because test and test is not a valid key and secret pair and a 401 unauthorized status code is returned. I've also created a JSON array in the application with several randomly generated keys and secrets. And as you can see, each key and secret also has a user email address and other important fields would normally be kept along with the key and secret, such as the name of the client and perhaps a description of the client's intended use of the API. But here a simple user email will allow us to trace back the key to a specific client. Let's select one of the keys and go back to our v1/drivers post endpoint and add that as an x-api-key header. And let's select a secret and add it as the x-api-secret header. I have x-api-key in all lowercase and x-api-secret in all uppercase just to demonstrate that case is ignored, so these will both work just fine. And now when we execute this request, the authorization succeeds and a 201 is returned. One final note about the key and the secret in the headers. This is the preferred manner of sending the key and secret to the server because adding them to the URL as query parameters would cause them to be displayed in plain text in server access logs that list full URLs of incoming requests. And placing the values in the request body would work for post requests but get requests, for example, do not have bodies. So an alternative mechanism would need to be used for get requests causing an inconsistency in the manner in which authentication parameters are sent to the server. So headers are a secure and standardized place where this type of information may be passed. Thanks for watching. Stay tuned for the next lesson where I will show you how to use the OAuth protocol for REST API security.