Primitive security mechanisms for APIs are API keys, HTTP Basic and HTTP Digest. They can be used when two parties are involved: the API consumer and the API provider. The API consumer needs to provide a secret (= password) as part of the API request, and the API provider authenticates and authorizes the request. In API scenarios, typically a third identity is involved, the identity of the end user. This allows scenarios, where a third party app of an API consumer gets access to the personal data of the end user via API. It might sound complicated, but it is a very common pattern in API design.
An example: Tim wants his tweets from Twitter to appear automatically on LinkedIn, so he can stay in touch with his business contacts. To realize this functionality, LinkedIn would need to have access to Tim’s Twitter account, to read the tweets. In this example, Tim is the end user, the third party app, and API consumer is LinkedIn, and Twitter is the API provider.
OAuth is a standard for delegating authorization, it is standardized in IETF RFC 6749. With OAuth, Tim gets an access token from Twitter and provides it to LinkedIn, thereby delegating his access rights to LinkedIn. The token represents the access rights for a subset of the data, for a short time frame. LinkedIn uses the access token to call the APIs of Twitter.
OAuth offers four grant types, which are used in different scenarios and can replace API keys, HTTP Basic and HTTP Digest. OAuth is the most popular and most secure way to protect an API. The exact interactions for the different OAuth grants should be studied by any API designer. Check out the OAuth Book for more details.
The OAuth standard primarily addresses the security concern of delegation, but complete OAuth solutions also address authentication and authorization.
Never Get Confused by OAuth Again — Get Your Copy of the OAuth Cheat Sheet!