API Keys vs HTTP Authentication vs OAuth in a RESTful API

I'm working on building a RESTful API for one of the applications I maintain. We're currently looking to build various things into it that require more controlled access and security. While researching how to go about securing the API, I found a few different opinions on what form to use. I've seen some resources say HTTP-Auth is the way to go, while others prefer API keys, and even others (including the questions I found here on SO) swear by OAuth.

Then, of course, the ones that prefer, say, API keys, say that OAuth is designed for applications getting access on behalf of a user (as I understand it, such as signing into a non-Facebook site using your Facebook account), and not for a user directly accessing resources on a site they've specifically signed up for (such as the official Twitter client accessing the Twitter servers). However, the recommendations for OAuth seem to be even for the most basic of authentication needs.

My question, then, is - assuming it's all done over HTTPS, what are some of the practical differences between the three? When should one be considered over the others?

It depends on your needs. Do you need:

• Identity – who claims to be making an API request?
• Authentication – are they really who they say they are?
• Authorization – are they allowed to do what they are trying to do?

or all three?

If you just need to identify the caller to keep track of volume or number of API Calls, use a simple API Key. Bear in mind that if the user you have issued the API key shares it with someone else, they will be able to call your API as well.

But, if you need Authorization as well, that is you need to provide access only to certain resources based on the caller of the API, then use oAuth.

Here's a good description: http://www.srimax.com/index.php/do-you-need-api-keys-api-identity-vs-authorization/

API Keys or even Tokens fall into the category of direct Authentication and Authorization mechanisms, as they grant access to exposed resources of the REST APIs. Such direct mechanisms can be used in delegation uses cases.

In order to get access to a resource or a set of resources exposed by REST endpoints, it is needed to check the requestor privileges according to its identity. First step of the workflow is then verifying the identity by authenticating the request; successive step is checking the identity against a set of defined rules to authorizing the level of access (i.e. read, write or read/write). Once the said steps are accomplished, a typical further concern is the allowed rate of request, meaning how many requests per second the requestor is allowed to perform towards the given resource(s).

OAuth (Open Authorization) is a standard protocol for delegated access, often used by major Internet Companies to grant access without providing the password. As clear, OAuth is protocol which fulfils the above mentioned concerns: Authentication and Authorization by providing secure delegated access to server resources on behalf of the resource owner. It is based on access Tokens mechanism which allow to the 3rd party to get access to the resource managed by the server on behalf of the resource owner. For example, ServiceX wants to access John Smith's Google Account on behalf of John, once John has authorized the delegation; ServiceX will be then issued a time-based Token to access the Google Account details, very likely in read access only.

The concept of API Key is very similar to OAuth Token described above. The major difference consists in the absence of delegation: the User directly requests the Key to the service provider for successive programmatic interactions. The case of API Key is time based as well: the Key as the OAuth Token is subject to a time lease, or expiration period. As additional aspect, the Key as well as the Token may be subject to rate limiting by service contract, i.e. only a given number of requests per second can be served.

To recap, in reality there is no real difference between traditional Authentication and Authorization mechanisms and Key/Token-based versions. The paradigm is slightly different though: instead of keep reusing credentials at each and every interaction between client and server, a support Key/Token is used which makes the overall interaction experience smoother and likely more secure (often, following the JWT standard, Keys and Tokens are digitally signed by the server to avoid crafting).

• Direct Authentication and Authorization: Key-based protocols as a variant of the traditional credentials-based versions.
• Delegated Authentication and Authorization: like OAuth-based protocols, which in turn uses Tokens, again as a variant of credential-based versions (overall goal is not disclosing the password to any 3rd party).

Both categories use a traditional identity verification workflow for the very first interaction with the server owning the interested resource(s).