12 the Open Protocol Oauth2 What Problems Does the Protocol Solve

12 The Open Protocol OAuth2 What Problems does the Protocol Solve #

Starting today, our discussion on security will shift from monolithic services to microservices architecture. For microservices architecture, the core considerations for security design are authentication and authorization. Since there are inter-service invocations within a microservices system, we need to consider both client requests and requests from other services for each service. Secure access control faces various authorization scenarios from client requests to services and from service to service. Therefore, we need to introduce a specialized authorization system for distributed environments, and the OAuth2 protocol is an effective solution for this application scenario.

An In-depth Look at the OAuth2 Protocol #

OAuth stands for Open Authorization, and this protocol solves the authorization problem, not the authentication problem. The widely adopted version of OAuth is the OAuth 2.0 protocol. OAuth2 is a relatively complex protocol that provides a clear definition of the roles and authorization models involved. Let’s continue reading for more details.

Use Cases for the OAuth2 Protocol #

In common e-commerce systems, there is usually a ticket processing system that relies on users’ basic information and also depends on their order records. To reduce development costs, let’s assume that our entire order module is not developed by ourselves, but integrated with an external order management platform. In order to generate ticket records, the ticket system must be able to read the user’s order records on the order management platform.

In this scenario, the difficulty lies in obtaining the user’s authorization to allow the ticket system to read the user’s order records on the order management platform. So, how does the ticket system obtain the user’s authorization? The typical method that comes to mind is for users to tell the ticket system their username and password on the order management platform, and then the ticket system logs in to the order management platform using the username and password to read the user’s order records. The entire process is shown in the following diagram:

Drawing 0.png

Illustration of user authentication and authorization interaction in the example system

Although this solution in the above diagram is feasible, it obviously has several serious drawbacks:

  • In order to continue providing subsequent services, the ticket system needs to store the user’s password on the order management platform, which is very unsafe. If the user’s password is accidentally leaked, it will lead to the leakage of user data on the order management platform.
  • The ticket system has the authority to obtain all the information that users store on the order management platform, and users cannot restrict the scope and validity period of the authorization obtained by the ticket system.
  • If the user changes the password for the order management platform, the ticket system will no longer be able to access the order management platform, which will cause a business interruption. However, we cannot restrict users from changing their passwords.

Since this solution has so many problems, is there a better way? The answer is yes, the emergence of the OAuth2 protocol is to address these problems.

First of all, regarding the security of passwords, in the OAuth2 protocol, passwords are still kept by users themselves, avoiding the leakage of sensitive information. Secondly, the authorization provided by the OAuth2 protocol has a clear scope and validity period. Users can limit the purpose and effectiveness of the authorization information obtained by the ticket system. Finally, if the user modifies their identity credentials such as passwords, they only need to reauthorize through the OAuth2 protocol, which will not affect other associated third-party applications.

Drawing 1.png

Comparison of traditional authentication and authorization mechanisms with the OAuth2 protocol

Roles in the OAuth2 Protocol #

One of the main reasons why the OAuth2 protocol is able to have these advantages lies in the good division of roles and responsibilities for the various actors involved in the entire system. The OAuth2 protocol defines four core roles: resource, client, authorization server, and resource server.

CddKJ1.png

Role definitions in the OAuth2 protocol

We can correlate the roles in OAuth2 with real-life application scenarios.

  • In the OAuth2 protocol, the interfaces or services that need to be accessed are collectively referred to as resources. Each resource has an owner, which in this example is the user.
  • The ticket system in the example represents a third-party application, commonly referred to as the client in the OAuth2 protocol.
  • Corresponding to the client, the OAuth2 protocol also has a service provider. In the example, the order management platform plays this role. The service provider has a resource server that stores user resources, and in this example, the order record is a type of user resource. The purpose of the authorization server is to complete the authorization process for the user and issue a token, which is what we call a Token.

Token in the OAuth2 Protocol #

At this point, you may ask, what exactly is the access token? The token is a very important concept in the OAuth2 protocol and is essentially a credential that represents the user’s identity. However, unlike ordinary username and password information, tokens have access permissions and validity periods specific to resources. The following is an example of common token information:

{
    "access_token": "0efa61be-32ab-4351-9dga-8ab668ababae",
    "token_type": "bearer",
    "refresh_token": "738c42f6-79a6-457d-8d5a-f9eab0c7cc5e",
    "expires_in": 43199,
    "scope": "webclient"
}

The above token information contains important fields that we will analyze in detail.

  • access_token: Represents the OAuth2 token. Users need to carry this token for authentication when accessing protected resources.
  • token_type: Represents the type of token. OAuth2 protocol has multiple token types, including Bearer type and MAC type. Here, the specified type is Bearer, which is the most commonly used type.
  • expires_in: Specifies the validity period of the access_token. Once this period is exceeded, the access_token will automatically become invalid.
  • refresh_token: When the access_token expires, a new access_token is issued using the refresh_token.
  • scope: Specifies the access scope. Here, it specifies the scope as “webclient”, which allows access to web resources.

Now that we have introduced the token, you may be curious about what exactly this token is used for. Next, let’s see how to use the token to complete the authorization process based on the OAuth2 protocol. The entire process is shown in the following diagram:

![Drawing 3.png](../images/CioPOWDewDyAFnrhAABs_ltusFE367.png)

Authorization Workflow based on the OAuth2 Protocol

We can further summarize the above process:

  1. First, the client requests authorization from the user. The request generally includes the resource’s access path and the type of operation on the resource. If the user agrees to the authorization, it will be returned to the client.
  2. Now, the client has obtained the user’s authorization information and can request an access token from the authorization server.
  3. The authorization server then issues an access token to the client, allowing the client to access resources on the resource server.
  4. Finally, the resource server verifies the validity and expiration time of the access token and grants access to the resources requested by the client.

Authorization Modes in the OAuth2 Protocol #

In the entire workflow, the most crucial step is the second step, which is to obtain valid user authorization. But how do we obtain user authorization? In OAuth 2.0, four authorization modes are defined: Authorization Code, Implicit, Password Credentials, and Client Credentials.

Let’s start with the most representative authorization code mode. When the user agrees to the authorization, the authorization server returns only an authorization code, not the final access token. In this mode, the client needs to exchange the authorization code for a token, which requires the client to have a backend service to interact directly with the authorization server.

![Drawing 4.png](../images/CioPOWDewEWARSNPAACJjFnruAQ327.png)

Authorization Code Mode Workflow

Here is a brief summary of the steps in the authorization code mode:

  1. First, when the user accesses the client, the client redirects the user to the authorization server. At this point, the user can choose whether to grant authorization to the client. Once the user agrees to the authorization, the authorization server will call back a callback address provided by the client’s backend service, and during the call, it will return an authorization code to the client.
  2. After receiving the authorization code, the client further requests a token from the authorization server.
  3. Finally, the authorization server verifies the authorization code and sends the access token to the client.

It is worth noting that the process of requesting a token from the authorization server using the authorization code is automatically done by the system and does not require user involvement. The user’s only requirement is to consent to the authorization at the start of the process.

Next, let’s look at another commonly used mode, the password mode, whose authorization process is shown in the following diagram:

![Drawing 5.png](../images/Cgp9HWDewE2Ab2vhAABPDH7Zxjo001.png)

Password Mode Workflow

As you can see, the password mode is simpler and easier to understand. The user only needs to provide their username and password, and the client will request a token from the authorization server based on this user information. After successful user authentication, the authorization server will issue the token.

The client mode and implicit mode in OAuth2 have less application in daily development, so we won’t go into detail here.

You may have noticed that although the OAuth2 protocol addresses the issue of authorization, it also applies to the concept of authentication. This is because we must verify the user’s identity credentials to complete the authorization process. Therefore, OAuth2 is actually a complex protocol that integrates security measures such as information digest and signature authentication, and requires token and key management behind the scenes.

OAuth2 Protocol and Microservices Architecture #

In the context of microservices systems, the service provider plays the role of the resource server, and the service consumer is the client. Each service can be both a client and a resource server, or even both. Once the client obtains a token, this token can be passed between various services. The following diagram illustrates this:

![Drawing 6.png](../images/CioPOWDewFaAKXrYAABQvvLUy-Q531.png)

Application of OAuth2 Protocol in Service Access Scenarios

In the entire OAuth2 protocol, the most important issue is how to obtain client authorization. In the current mainstream microservices architecture, when we initiate an HTTP request, the focus is on how to transmit the token transparently and efficiently through the HTTP protocol. In this case, the authorization management method of the authorization code mode using a callback address is not practical, and the password mode is more concise and efficient. Therefore, in this column, we will use the password mode as the default implementation method for OAuth2 protocol authorization mode.

Summary and Preview #

Today, we have delved into the field of microservices security, where authentication and authorization are still the fundamental security control measures. By analyzing the authentication and authorization solutions in the microservices architecture, we introduced the OAuth2 protocol, which is the mainstream authorization protocol in the microservices architecture. We provided a detailed explanation of the roles, authorization modes, and integration relationship between OAuth2 and microservices architecture.

The summary of the content covered in this lecture is as follows:

![Drawing 7.png](../images/CioPOWDewF2AG8SOAAGkQKcZcsU075.png)

Finally, here is a question for you to think about: Can you describe the four roles and four authorization modes in the OAuth2 protocol? Feel free to share your insights in the comments section.