How to easily secure your APIs with API keys and OAuth?

Securing your API does sound like a complicated thing, but there are some basic things you can consider setting up your API in a more secure way than just exposing it widely open to the public.
Authenticating the consumer is a first step towards:

• Being able to say who is consuming what and how much;
• Allowing you to block people that misbehave or are no longer authorized.

API Key

Introducing API keys is an easy thing. Just issue a “secret” or “phrase” between you and the consumer. Every time the API is called this Key must present and the API proxy will be able to verify it. This works well for most use cases; however, some best practices need to be considered.

For example, you should avoid putting the API Key inside the URL as a “query parameter” because proxies and all involved systems are likely to store it into their logs. Better places are Header or Payload. The header has turned out to be the most practical place.
Just having a phrase that is sent every time with each request does not sound very secure, does it? People just need to capture one request to get access to the entire API. In some cases, that’s totally fine, but there needs to be ways to uplift the security.

One way is to extend the Authentication with an additional Secret that needs to be provided too. This alone does not introduce more security, but you can use this to do some smart things like HMAC.
HMAC starts to include an encrypted signature as API key instead of submitting the real key. With some nice additions like a timestamp this signature can be a really powerful way to introduce protection.

See how Amazon Web Services style API keys have been designed including a key ID and a secret key which are used together to authenticate securely the client. The API key ID is included in all requests to identify the client. The secret key is known only to the client and the API Gateway. It’s will require some code on your client and Server but most languages and frameworks provide support. To learn more, check out this blog post to learn how to protect your API Keys.

OAuth

While the Secret Key is always traveling with your request, OAuth provides an alternative solution. OAuth is basically a way to separate the Authentication Process from the Access to the Resource and therefore limit the exposure of the credentials. Delegation is the secret. Instead of sending the credentials, the user retrieves a token that will then be used to access the resource.
Some usage examples could be:

• A Gmail user would like LinkedIn to access their contact list without sharing their Gmail username and password;
• A photo printing website user would like the website to access his pictures on Flickr;
• A company would like its customers to access a subset of their services through a partner website without the partner knowing the customer credentials;
• A company would like to develop a mobile app where the user credentials are never stored on the mobile app.

One scenario you see often is Social Login where you use GitHub, LinkedIn, Google or Facebook to log into a Web app. You might have recognized the Consent Screen that usually talks about which data the Web app would like to read from your Git or Facebook account. If you accept, then you “Grant Access” and the resource can be opened on behalf. This is usually known as “3-legged OAuth Flow” or “Authorization Code Grant Flow.”

Be aware there are some caveats with OAuth 2.0, it’s not secure by default!

Summary

Protecting your API does not have to be difficult. API Key as well as OAuth are a first step toward a more secure API. Please note that API throttling and quota limits should also be applied together with other measures. API Key can be an easy way to enforce some authentication. OAuth is more sophisticated with more options but also needs more knowledge to get implemented correctly, not only on the client but also on the server-side. API Management tools provide an easy way to protect your APIs and turn on authentication with a few clicks.