Oauth 2.0

 OAuth 2.0 is an authorization framework developed by the Internet Engineering Task Force (IETF) OAuth working group.

The fundamental focus of OAuth 2.0 is to fix the access delegation problem. OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0, and the OpenID Foundation developed the OpenID Connect specification.

A.1 The access delegation problem

If you want someone else to access a resource (a microservice, an API, and so on) on your behalf and do something with the resource, you need to delegate the corresponding access rights to that person (or thing). For example, if you want a third-party application to read your Facebook status messages, you need to give that third-party application the corresponding rights to access the Facebook API. There are two models of access delegation:

• Access delegation via credential sharing

• Access delegation with no credential sharing

If we follow the first model, we need to share our Facebook credentials with the third-party application so it can use the Facebook API, authenticate with our credentials, and read our Facebook status messages. This is quite a dangerous model (we are using Facebook just as an example; however, it does not support this model).

Once you share your credentials with a third-party application, it can do anything, not just read your Facebook status messages. It can read your friends list, view your photos, and chat with your friends via Messenger. This is the model many applications used before OAuth.

Figure A.1 A third-party application follows the model of access delegation with no credential sharing in order to get a temporary token from Facebook, which is only good enough to read a user’s status messages.

With OAuth 2.0, the third-party web application first redirects the user to Facebook (where the user belongs). Facebook authenticates and gets the user’s consent to share a temporary token with a third-party web application, which is only good enough to read the user’s Facebook status messages for a limited time. Once the web application gets the token from Facebook, it uses the token along with the API calls to Facebook.

The temporary token Facebook issues has a limited lifetime and is bound to the Facebook user, the third-party web application, and the purpose. The purpose of the token here is to read the user’s Facebook status messages, and the token should be only good enough to do just that and no more. The OAuth 2.0 terminology is as follows:

• The Facebook user is called the resource owner. The resource owner decides who should have which level of access to the resources owned by that resource owner.

• Facebook, which issues the token, is called the authorization server. The authorization server knows how to authenticate (or identify) the resource owner, and grants access to third-party applications to access resources owned by the resource owner, with their consent.

• The Facebook API is called the resource server. The resource server guards the resources owned by the resource owner, and lets someone access a resource only if the access request comes along with a valid token issued by the authorization server.

• The third-party web application is called the client. The client consumes a resource on behalf of the resource owner.

• The token Facebook issues to the third-party web application is called the access token. The authorization server issues access tokens, and the resource server validates those. To validate an access token, the resource server may talk to the authorization server.

• The purpose of the token is called the scope. The resource server makes sure a given token can be used only for the scope attached to it. If the third-party application tries to write to the user’s Facebook wall with the access token it got to read the status messages, that request will fail.

• The flow of events that happens while the third-party web application gets the token is called a grant flow, which is defined by a grant type. OAuth 2.0 defines a set of grant types, which we discuss in section A.4.

In a typical access delegation flow, a client accesses a resource that’s hosted on a resource server on behalf of an end user (or a resource owner) with a token provided by an authorization server. This token grants access rights to the client to access a resource on behalf of the end user.

Actors of Oauth 2.0

• The resource server

• The client

• The end user (also known as the resource owner)

• The authorization server

The standard OAuth 2.0 specification identifies five main grant types. Each grant type outlines the steps for obtaining an access token. The result of executing a particular grant type is an access token that can be used to access resources on your microservices. The following are the five main grant types highlighted in the OAuth 2.0 specification:

• Client credentials --Suitable for authentication between two systems with no end user (we discuss this in section A.4.1)

• Resource owner password --Suitable for trusted applications (we discuss this in section A.4.2)

• Authorization code --Suitable for almost all the applications with an end user (we discuss this in section A.4.4)

• Implicit --Don’t use it! (we discuss this in section A.4.5)

• Refresh token --Used for renewing expired access tokens (we discuss this in section A.4.3)

Actors in an OAuth2.0 flow: in a typical access delegation flow, a client--on behalf of the end user--accesses a resource that is hosted on a resource server by using a token provided by the authorization server.

The Order Processing microservice, which plays the role of the resource server here, would receive the token issued by the authorization server from the client, usually as an HTTP header or as a query parameter when the client makes an HTTP request (see step 1 in figure 2.4). It’s recommended that the client communicate with the microservice over HTTPS and send the token in an HTTP header instead of a query parameter. Because query parameters are sent in the URL, those can be recorded in server logs. Hence, anyone who has access to the logs can see this information.

Having TLS to secure the communication (or in other words, the use of HTTPS) between all the entities in an OAuth 2.0 flow is extremely important. The token (access token) that the authorization server issues to access a microservice (or a resource) must be protected like a password. We do not send passwords over plain HTTP and always use HTTPS. Hence we follow the same process when sending access tokens over the wire.

Here’s what happens in each of the steps illustrated in figure 2.6:

1. The client application requests an OAuth2.0 access token from the authorization server.

2. In response to the request in step 1, the authorization server issues an access token to the client application.

3. The client application makes an HTTP request to the Order Processing microservice. This request carries the access token obtained in step 2 as an HTTP header.

4. The Order Processing microservice checks with the authorization server to see whether the received access token is valid.

5. In response to the request in step 4, the authorization server checks to see whether the provided access token is an active token in the system (its state is active) and whether the token is valid for that particular moment (it isn’t expired). Then it responds to the Order Processing microservice, indicating whether the access token is valid.

6. In response to the request in step 3, and based on the result in step 5, the Order Processing microservice responds to the client application, either granting access to the resource being requested or sending an error message.

In the examples in this chapter so far, you’ve used the client_credentials grant type to obtain an access token from the authorization server.