02 Why Must Authorization Code Grant Type Have an Authorization Code #

Hello, I am Wang Xindong.

In the previous lecture, I mentioned the authorization code grant type of OAuth 2.0. In the example of the Little Rabbit Print-on-Demand software, Little Rabbit ultimately accessed the order data in Xiao Ming’s store through an access token. At the same time, I also mentioned that this access token is obtained by exchanging an authorization code. At this point, you might wonder, why do we need to exchange an authorization code for the token? Why can’t we simply issue the access token directly?

You can take a moment to think about this question. In today’s lesson, I will delve into the logic behind it.

Why do we need an authorization code? #

Before discussing this question, let’s synchronize our understanding. In the OAuth 2.0 framework, there are four roles according to the official terminology: resource owner, client, authorization server, and protected resource. However, in this course, we will refer to the client as a third-party software. So, throughout our explanation, I will consistently use the term “third-party software.”

Therefore, when you refer to the official documentation, you can make the corresponding associations. For better understanding, let’s continue using the example of Little Rabbit Software. In this case, the resource owner corresponds to Xiao Ming, the third-party software corresponds to Little Rabbit Software, the authorization server corresponds to the JD.com Merchant Open Platform’s authorization server, and the protected resource corresponds to the orders from Xiao Ming’s store on JD.com.

Now that we have understood these concepts, let’s continue.

You may know that OAuth was originally created to address authorization issues in the web browser scenario. So, based on the browser scenario, and building upon the overall process of Xiao Ming using Little Rabbit Software to print orders discussed in the previous lesson, I have created a sequence diagram for the authorization code grant type.

Of course, Little Rabbit Software will continue to accompany us in this explanation. However, this time, in order to better illustrate the authorization code grant flow, I will separate the frontend and backend of Little Rabbit Software. I will also split the JD.com Merchant Open Platform’s system into the components of the authorization server and the protected resource service, according to the OAuth 2.0 architecture. The diagram below illustrates this:

Figure 1: Sequence diagram for the authorization code grant type using Little Rabbit Software as an example

Seeing this sequence diagram with so many additional steps, you might feel a bit nervous. And if I tell you that there are even more steps if we go into further detail, you might feel even more confused.

However, don’t worry, this is not a problem. On one hand, the focus of this lesson is on the steps related to the authorization code, so you only need to pay attention to the key steps, which are the ones related to the two redirects. In the next lesson, I will teach you how to further break down these steps. On the other hand, I will analyze this flow from another perspective to help you understand it better.

Let’s continue looking at this sequence diagram. From the diagram, we can see that in step 4, the authorization server generates an authorization code. Going back to the question we raised earlier, if we didn’t need an authorization code, we could have directly returned the access token at this step.

Thinking along the lines of not having an authorization code, if we directly returned the access token here, we definitely couldn’t use the redirection approach. This is because exposing the access token, which has high security and confidentiality requirements, in the browser would pose a significant security risk of the access token being stolen. Clearly, this cannot be allowed. In other words, if there is no authorization code, we can only send the access token to the backend service of the third-party software Xiaotu. According to this logic, the process diagram above would look like this:

Figure 2: If there is no authorization code, send the access token directly to the backend service of the third-party software Xiaotu.

So far, it seems seamless. Xiaoming accesses the Xiaotu software, which says it needs authorization in order to print invoices. Otherwise, Jingdong (JD) won’t cooperate. Then, Xiaotu software guides Xiaoming to redirect to JD’s authorization service. After reaching the authorization service, JD Open Platform verifies the legality of Xiaotu and Xiaoming’s login status, and generates an authorization page. Next, Xiaoming quickly clicks “Agree” to authorize. At this point, JD Open Platform knows that Xiaoming’s order data can be given to Xiaotu software.

Therefore, JD Open Platform quickly generates an access token (access_token) and returns it to Xiaotu software through the backend service. Now, Xiaotu software can work properly.

Here’s the problem: When Xiaoming is redirected to the authorization service by the browser, the “connection” between Xiaoming and Xiaotu software is interrupted. It’s as if at this moment, after Xiaoming establishes a “connection” with the authorization service, he will remain “stuck on the authorization service page.” You can see from the sequence in Figure 2 that Xiaoming never “reconnects” to Xiaotu software.

However, Xiaotu software has already obtained the access token after Xiaoming’s authorization and has used it to retrieve orders data from Xiaoming’s store. At this point, considering “Xiaoming’s experience,” Xiaotu software should notify Xiaoming, but how can it be done? Now that the “connection is lost,” it may not be so easy.

In order to allow Xiaotu software to easily notify Xiaoming, it is necessary to reestablish the “connection” between Xiaoming and Xiaotu software. This is what we see as the second redirection. After Xiaoming authorizes, he is redirected back to the Xiaotu software’s address, so that Xiaoming has a new “connection” with Xiaotu software.

At this point, you can understand why there is a need for two redirections in the authorization code grant flow.

To reestablish such a connection, we cannot expose the access token, and thus we have this temporary and indirect credential: the authorization code. Because what Xiaotu software ultimately needs is an access token with high security and confidentiality requirements, not the authorization code, which can be exposed in the browser. This way, with the participation of the authorization code, the access token can be transmitted between backend services, and at the same time, a “connection” between Xiaoming and Xiaotu software can be reestablished. Thus, through an authorization code, we take care of Xiaoming’s experience and also address communication security.

Now you understand why there is a need for an authorization code.

So, how does the authorization code and the access token circulate between Xiaotu software and the authorization service in the execution of the authorization code grant flow? To answer this question, we need to continue analyzing the communication process of the authorization code grant type.

Communication Process of Authorization Code Grant Type #

There are 9 steps identified in the communication process shown in Figure 1. Analyzing them step by step may seem complex, so I will use another approach to help you understand, which is to analyze it based on the dimensions of direct communication and indirect communication. Here, indirect communication refers to the interaction of obtaining the authorization code, while direct communication refers to the interaction of exchanging the authorization code for an access token.

Next, let’s analyze it together and see which parts are indirect communication and which parts are direct communication.

Indirect Communication #

Let’s first analyze why it is “indirect.”

Let’s “magnify” the process of obtaining the authorization code (code) in Figure 1 and take a different perspective, placing the browser as a proxy between the third-party software “Little Rabbit” and the authorization service. Then, we come to the following illustration:

This process seems to have the following conversation:

Little Rabbit software: “Okay, I will redirect you to the authorization service, and I need the authorization service to give me an authorization code.”

Notice that there is no direct communication between the third-party software “Little Rabbit” and the authorization service. Instead, it is “mediated” by the browser. Therefore, we say that this is a form of indirect communication.

Direct Communication #

Now let’s analyze the interaction of exchanging the authorization code for an access token and understand why it is “direct.” Let’s “magnify” the process of obtaining the access token in Figure 1 to obtain the following illustration:

Compared to the indirect communication process of obtaining the authorization code, it is easier to understand the direct communication process of obtaining the access token. It is the interaction where the third-party software “Little Rabbit,” after obtaining the authorization code (code) value, initiates a communication request to the authorization service to obtain the access token. This request is the communication between the third-party software server and the authorization service server, all happening in the backend server, so it is also called backend communication.

Two “Alliances” #

After understanding the communication methods mentioned above, you may have realized that the 4 roles in OAuth 2.0 are split into two “teams”: the resource owner and the third-party software “stand together” because the third-party software represents the resource owner to access protected resources, while the authorization service and the protected resources “stand together” because the authorization service is responsible for issuing access tokens and the protected resources are responsible for receiving and validating access tokens.

At this point, you may have noticed that throughout this explanation of the authorization code flow, I used the scenario of involving a browser. However, is it necessary for the browser to be involved in this flow?

In fact, the authorization code grant flow does not necessarily require the involvement of a browser. Next, let’s continue analyzing its logic.

Is a browser necessary? #

At the beginning of the development of OAuth 2.0, the open ecosystem was relatively limited, and web applications that acted as proxies through browsers were the majority. The authorization code grant type was naturally applied to web applications that required browser access.

However, in reality, OAuth 2.0 is a concept of authorization, or a way of thinking about authorization. The mindset of the authorization code grant type can be applied to many scenarios, such as WeChat mini programs. When developing a WeChat mini program, we obtain user login information through the authorization code grant type. In the example provided in the official documentation, the parameter grant_type=authorization_code is used, without the need for a browser.

According to the WeChat official documentation, the process of obtaining user login status information by developers is indeed an authorization code grant process:

First, developers use the wx.login(Object object) method to obtain the login credential code. This step is implemented within the mini program by calling the SDK provided by WeChat.

Then, the code value is exchanged for the user’s session_key and other information, which is achieved through the auth.code2Session method mentioned in the official documentation. It is strongly recommended to call this method through the developer’s backend service.

As you can see, this process does not involve the use of a browser, but it does follow the idea of the authorization code grant type. In other words, the code value is obtained by the mini program frontend, and then the code value is exchanged for the session_key and other information using the mini program’s backend service. The only difference is that the value of the access token, access_token, is replaced by the session_key.

As you can see, this entire process embodies the mindset of the authorization code grant type.

Summary #

We are nearing the end of this lesson, so let’s review the key points again.

Today, I started by discussing why we need authorization codes, and I explained the overall communication process of the authorization code grant flow using authorization codes. I mentioned the problems solved by this type of authorization and the communication methods used in the authorization code flow. In summary, I want you to remember the following two points.

The authorization code grant flow has two communication methods. The first is front-end communication, as it facilitates the interaction process of the authorization code through the browser. For example, the authorization service of the JD Seller Open Platform generates an authorization code and sends it to the browser, and the third-party software “XiaoTu” fetches the authorization code from the browser. Because XiaoTu and the authorization service do not directly contact each other during the authorization code retrieval, this is also known as indirect communication. The second method is back-end communication. After XiaoTu obtains the authorization code, it directly initiates a request to exchange it for an access token, which is also known as direct communication.

In OAuth 2.0, access tokens are required to have high security and confidentiality. Therefore, we cannot expose them in the browser and can only obtain and use them through the back-end service of third-party software like XiaoTu, ensuring the maximum security of access tokens. Because of this security requirement for access tokens, when front-end communication is needed, such as when there is interaction in the browser, OAuth 2.0 provides a temporary credential: the authorization code. With the authorization code, user Xiao Ming, after granting authorization to XiaoTu on the authorization service, can return to the operation page of XiaoTu. This way, security is ensured while enhancing Xiao Ming’s experience on XiaoTu.

From the authorization code grant flow, we can see that it perfectly organizes the four roles of OAuth 2.0 and ensures smooth communication among them. The structure and ideas proposed can be applied to other environments or protocols, such as using authorization code grants in WeChat mini programs.

However, it is precisely because of the involvement of the authorization code that the authorization code grant flow has more steps compared to other authorization grant types, making it the most complete and secure authorization flow in the OAuth 2.0 system. In the next two lessons, I will focus on explaining the authorization service under the authorization code grant type.

Thought-provoking Questions #

Alright, we’re almost finished with today’s lecture, and I have a thought-provoking question for you.

Regarding authorization code grant flow that doesn’t require a browser’s involvement, can you think of more application scenarios?

Feel free to share your opinions in the comment section. You’re also welcome to share today’s content with your friends for a discussion together.