tl;dr: OAuth 2.0

The prime goal of OAuth 2.0 is to let users, in their capacity of resource owners, grant clients limited access to resources they control. Resources reside on resource servers which require an access token for access. Access tokens are issued by an authorization server. This is a departure from previous protocols where a client would receive user credentials with which it could impersonate the resource owner. Instead of users having to completely trust the client, they can, and should, limit the privileges they grant the client to those needed for the job at hand. This mitigates the risk of a malicious client and limits the impact of a client compromise.

OAuth 2.0 defines 3 ways in which the client can prove its entitlement to access a resource:

• Authorization Code Grant
• Implicit Grant
• Resource Owner Password Grant

It also defines a 4th grant type where the client is also the resource owner, the Client Credentials Grant.

The protocol in the first 3 grant types involves 5 parties,

• the resource owner or user,
• the user agent, e.g. the browser,
• the client, e.g. a Single Page Application implemented in JavaScript and running in the browser,
• the authorization server and
• the resource server, or, in other words, the REST API.

In the 4th grant type, resource owner and client coincide.

Neither in the Authorization Code nor in the Implicit Grant are client credentials handed to the client: when an access token is required, the client redirects the user agent to the authorization server. If the resulting interaction between resource owner and authorization server completes successfully, the user is redirected back to the client with a token which can be used to unlock access to resource servers.

When using the Resource Owner Password or Client Credentials Grant, on the other hand, resource owner credentials are exposed to the client. Hence it has been argued that these grant types do not afford better protection than Basic Authentication. Nonetheless, their use is a step in the right direction as it enables centralisation of STS and IdP - see my previous blog on this topic.

In the past, OAuth has frequently been misused for authentication. With the increasingly widespread adoption and tool support for OpenID Connect, the temptation to do so has diminished.