APIs handle enormous amounts of data of a widely varying type – accordingly, one of the chief concerns of any data provider is how specifically to secure this data. The idea that data should be secret, that it should be unchanged, and that it should be available for manipulation is key to any conversation on API data management and handling.

Today, we’re going to talk about Authentication. Though an often discussed topic, it bears repeating to clarify exactly what it is, what it isn’t, and how it functions.

We’ll highlight three major methods of adding security to an API — HTTP Basic Auth, API Keys, and OAuth. We’ll identify the pros and cons of each approach to authentication, and finally recommend the best way for most providers to leverage this power.

Authentication vs Authorization

Before we dive into this topic too deep, we first need to define what authentication actually is, and more importantly, what it’s not. As much as authentication drives the modern internet, the topic is often conflated with a closely related term: authorization.

The two functions are often tied together in single solutions – in fact, one of the solutions we’re going to discuss in a moment is a hybrid system of authentication and authorization. As such, and due to their similarities in functional application, it’s quite easy to confuse these two elements.

The easiest way to divide authorization and authentication is to ask: what do they actually prove? In simple terms, Authentication is when an entity proves an identity. In other words, Authentication proves that you are who you say you are. This is akin to having an identification card – an item given by a trusted authority that the requester, such as a police officer, can use as evidence that suggests you are in fact who you say you are.

Authorization is an entirely different concept, though it is certainly closely related. In simple terms, Authorization is when an entity proves a right to access. In other words, Authorization proves you have the right to make a request. When you try to go backstage at a concert or an event, you don’t necessarily have to prove that you are who you say you are – you furnish the ticket, which is de facto proof that you have the right to be where you’re trying to get into.

Consider for a moment a driver’s license. In many countries, a driver’s license proves both that you are who you say you are via a picture or other certified element, and then goes further to prove that you have a right to drive the vehicle class you’re driving. In such a case, we have authentication and authorization – and in many API solutions, we have systems that give a piece of code that both authenticates the user and proves their authorization. In such a case, we have hybrid solutions.

Therefore, moving forward, it’s important to remember that what we’re actually talking about here is a system that proves your identity – nothing more, nothing less.

Common Methods of API Authentication

While there are as many proprietary authentication methods as there are systems which utilize them, they are largely variations of a few major approaches. These approaches almost always were developed to solve limitations in early communications and internet systems, and as such, typically use broad existent architectural approaches with novel implementations in order to allow authentication to occur.

HTTP Basic Authentication

HTTP Basic Auth is rarely recommended due to its inherent security vulnerabilities.

One solution is that of HTTP Basic Authentication. In this approach, an HTTP user agent simply provides a username and password to prove their authentication. This approach does not require cookies, session IDs, login pages, and other such specialty solutions, and because it uses the HTTP header itself, there’s no need to handshakes or other complex response systems.

The problem is that, unless the process is strictly enforced throughout the entire data cycle to SSL for security, the authentication is transmitted in open on insecure lines. This lends itself to man in the middle attacks, where a user can simply capture the login data and authenticate via a copy-cat HTTP header attached to a malicious packet.

Additionally, even if SSL is enforced, this results in a slowing of the response time. And even ignoring that, in its base form, HTTP is not encrypted in any way. It is encapsulated in base64, and is often erroneously proclaimed as encrypted due to this.

HTTP Basic Authentication does have its place. In an internal network, especially in IoT situations where speed is of no essence, having an HTTP Basic Authentication system is acceptable as a balance between cost of implementation and actual function. As a general authentication solution, however, HTTP Basic Authentication should be seldom used in its base form.

API Keys

API keys are an industry standard, but shouldn’t be considered a holistic security measure.

API Keys were created as somewhat of a fix to the early authentication issues of HTTP Basic Authentication and other such systems. In this approach, a unique generated value is assigned to each first time user, signifying that the user is known. When the user attempts to re-enter the system, their unique key (sometimes generated from their hardware combination and IP data, and other times randomly generated by the server which knows them) is used to prove that they’re the same user as before.

On one hand, this is very fast. The ability to prove identity once and move on is very agile, and is why it has been used for many years now as a default approach for many API providers. Additionally, setting up the system itself is quite easy, and controlling these keys once generated is even easier. This also allows systems to purge keys, thereby removing authentication after the fact and denying entry to any system attempting to use a removed key.

The problem, however, is that API keys are often used for what they’re not – an API key is not a method of authorization, it’s a method of authentication. Because anyone who makes a request of a service transmits their key, in theory, this key can be picked up just as easy as any network transmission, and if any point in the entire network is insecure, the entire network is exposed. This makes API keys a hard thing to recommend – often misused and fundamentally insecure, they nonetheless do have their place when properly secured and hemmed in by authorization systems.

OAuth

OAuth combines Authentication and Authorization to allow more sophisticated scope and validity control.

OAuth is a bit of a strange beast. OAuth is not technically an authentication method, but a method of both authentication and authorization. When OAuth is used solely for authentication, it is what is referred to as “pseudo-authentication.”

In this approach, the user logs into a system. That system will then request authentication, usually in the form of a token. The user will then forward this request to an authentication server, which will either reject or allow this authentication. From here, the token is provided to the user, and then to the requester. Such a token can then be checked at any time independently of the user by the requester for validation, and can be used over time with strictly limited scope and age of validity.

This is fundamentally a much more secure and powerful system than the other approaches, largely because it allows for the soft establishment of scope (that is, what systems the key allows the user to authenticate to) and validity (meaning the key doesn’t have to be purposely revoked by the system, it will automatically become deprecated in time).

As with anything, there are some major pros and cons to this approach. On the one hand, it’s clearly superior when it comes to the level of security it can offer, and for this reason, OAuth is quickly becoming the de facto choice for anyone choosing to eschew API keys. On the other hand, using OAuth for authentication alone is ignoring everything else that OAuth has to offer – it would be like driving a Ferrari as an everyday driver, and never exceeding the residential speed limits.

Those caveats in mind, OAuth is easy to set up, and it is incredibly fast.

The Best Option

So of these three approaches, two more general and one more specific, what is the best? That’s a hard question to answer, and the answer itself largely depends on your situations. While the clear winner of the three approaches is OAuth, there are some use cases in which API keys or HTTP Basic Authentication might be appropriate.

That being said, these use cases are few and far in-between, and accordingly, it’s very hard to argue against OAuth at the end of the day. OAuth delivers a ton of benefits, from ease of use to a federated system module, and most importantly offers scalability of security – providers may only be seeking authentication at this time, but having a system that natively supports strong authorization in addition to the baked-in authentication methods is very valuable, and decreases cost of implementation over the long run.

What do you think? What’s the best way to authenticate a user? More to the point, what do you think are the most clear use cases for using something like an API key over OAuth? Let us know in the comments below.