10 Serial Talk on the Working Process and Security Issues of OAuth 2 #
Hello, I am Wang Xindong.
In today’s lecture, I don’t intend to solve any new problems. Instead, I will recap the content we have covered, similar to a summary at the end of a semester during our student days, to review the entire knowledge system of OAuth 2.0. Of course, during this process, I will also share with you the most valuable experiences I have accumulated while implementing OAuth 2.0.
Alright, let’s start by reviewing the workflow of OAuth 2.0.
OAuth 2.0 Workflow Explained #
We have been talking about OAuth 2.0 as an authorization protocol that allows third-party software to perform permitted actions on behalf of users. Therefore, the third-party software needs to obtain authorization from the user to obtain that token.
Let’s think back to the example of visiting Baidu’s CEO in Lesson 1. You can only enter Baidu’s building with the access card given to you by the receptionist. This process is equivalent to the receptionist authorizing you, and the access card serves as the authorization token. In our system, the access card is equivalent to the access token.
Through keywords like “represent” and “authorize,” we can understand that OAuth 2.0 is an authorization protocol and a security protocol. So, don’t be surprised if I say it is also a delegation protocol.
Imagine that users on the WeChat platform have permissions to modify their nickname, avatar, and personal interests. When a third-party software requests to represent the user to perform these permissions, it is requesting the user to delegate these permissions to itself. Only after the user approves the delegation request can the third-party software act on behalf of the user.
At this point, let’s think about it carefully: delegation is the foundation of the OAuth 2.0 authorization concept because without the concept of “delegation,” there would be no “representation.”
Throughout the course of explaining the authorization process, I frequently used the authorization code grant flow as an example. When learning about the authorization code flow, you were probably most confused about why there is an additional step to exchange an authorization code for an access token. I analyzed this question in Lesson 2, and now you should not be “painfully tortured” by it anymore.
Let’s analyze it further. A third-party software can obtain an access token through two channels:
One channel is the front-end page of the third-party software. However, if the access token is directly returned to the front-end page, it can easily be intercepted through the browser, which is obviously not advisable.
The other channel is through back-end communication. The third-party software’s back-end communicates with the authorization service’s back-end, which avoids the direct exposure of the token.
Moreover, the third-party software’s back-end cannot simply “force” the authorization service’s back-end without informing it which user’s access token it needs. Therefore, user involvement is necessary.
Once the user is involved, the first page they visit is the third-party software’s page, where the user needs to grant authorization. The third-party software needs to redirect the user to the authorization service’s page. However, at this point, there is no “communication connection” between the user and the third-party software. If the authorization service directly gives the token to the third-party software’s back-end through back-end communication, it would be difficult to notify the user.
In this scenario, the authorization code is cleverly introduced: first, the code is returned to the third-party software’s page via a redirect. After obtaining the code through the browser, the third-party software exchanges it for an access token through back-end communication. Once the token is obtained, because the user is already on the third-party software’s service, it is easy to notify the user.
The above is the overall workflow of the authorization code grant. We say this is the most complete flow in the OAuth 2.0 authorization system. Other types of authorization grants, such as resource owner password credentials grant, client credentials grant, and implicit grant, are based on this. Therefore, as long as you understand the workflow of the authorization code grant, you have grasped the operation mechanism of all authorization grant types in OAuth 2.0. Using OAuth 2.0 in practical work scenarios will no longer be a problem.
Explanation of OAuth 2.0 Security Issues #
However, things are not all smooth sailing here. We have only solved the basic usage issues of OAuth 2.0. In order to use and apply this protocol correctly and become an expert in its application, we must pay attention to the security issues of OAuth 2.0.
During the process of implementing OAuth 2.0, we must also follow the specification recommendations, otherwise we will trigger a series of security issues. This often leads to the question from some students, isn’t OAuth 2.0 secure? Doesn’t it protect thousands of web APIs on the Internet? Don’t we say that it is a secure protocol?
First of all, it is true to say that OAuth 2.0 is a secure protocol, but improper use can also lead to security issues. For example, in the [8th lesson], we mentioned a widespread issue of cross-site request forgery. The reason for such security issues is because we did not follow the usage recommendations of OAuth 2.0, such as not using parameters like “state” to verify requests, or not following the recommendation that “code” values can only be used once and the binding relationship between used code values and token values should be cleared.
In terms of security issues, there is one point that we have not specifically mentioned, that is in the process of using OAuth 2.0, we need to use the HTTPS protocol for HTTP communication to ensure the security of data transmission. This is because the bearer token type that OAuth 2.0 supports, which is any string format token, does not provide or require the use of information signing mechanisms.
You might say that JWT tokens have such encryption mechanisms. However, this precisely demonstrates that OAuth 2.0 is a set of rules that does not constrain ordinary tokens, which is why JWT serves as an additional supplement to OAuth 2.0.
In fact, JWT is not directly related to OAuth 2.0, it is simply a structured information storage that can be used anywhere other than OAuth 2.0. For example, when resetting a password, an email is sent to you with a link that needs to be able to identify who the user is, cannot be tampered with, and has a validity period of 5 minutes. These characteristics are consistent with JWT. In other words, JWT is not covered by the OAuth 2.0 protocol specification.
OAuth 2.0 seems to lack its own rules and constraints, or rather, it is committed to being a good authorization framework. Through our previous study, we can verify that it does indeed excel in this work.
In addition, OAuth 2.0 provides basic support with an open mindset, such as the OpenID Connect (OIDC) identity authentication protocol framework discussed in [Lesson 9]. This open approach allows us to use “OAuth 2.0 + another technology” to create a new technology. This is a great and practical combination that can meet the needs of different scenarios.
Perhaps because OAuth 2.0 can support identity authentication protocols like OIDC, we always “insist” that OAuth 2.0 is an identity authentication protocol. Of course, OAuth 2.0 is not an identity authentication protocol. I used the analogy of “flour” and “bread” to explain the relationship between OAuth 2.0 and OIDC in Lesson 9.
Allow me to explain further. What is the reason behind this “misunderstanding” of OAuth 2.0? I think the main reason is that OAuth 2.0 does indeed include content related to identity authentication, that is, the authorization service requires users to log in before confirming their authorization.
However, such a process alone is not enough to make OAuth 2.0 a true user identity authentication protocol. This is because OAuth 2.0 only cares about two things: issuing tokens and using tokens, and the token is opaque to third-party software. At the same time, the protected resource service does not care which user is making the request, as long as a valid token is submitted, it will provide the correct response and return data to the third-party software.
So far, we have discussed the content closely related to the security issues of OAuth 2.0. I hope that at this point, you can integrate and understand the core knowledge of OAuth 2.0 according to your own understanding. Next, I will share with you one of the most profound issues I have encountered during the process of implementing OAuth 2.0.
Emphasizing the Importance of Security Awareness #
Based on my years of experience on the open platform, security awareness is an issue that cannot be emphasized enough in the process of implementing OAuth 2.0.
In summary, it can be said that if there is any opportunity to “make a big mistake” while using OAuth 2.0, it is definitely in terms of security: OAuth 2.0 is dedicated to protecting open web APIs and users’ resources on the platform. If security issues arise from improper use of OAuth 2.0, it is indeed a very embarrassing situation.
There are only two parties in the OAuth 2.0 process that can contribute to security: third-party developers and platform owners. However, the level of security awareness among third-party developers varies. Therefore, platform owners need to emphasize this point in their official documentation and provide solutions for common security vulnerabilities. At the same time, internal developers who are part of the platform also cannot ignore security issues and should have a higher level of security awareness and understanding.
Only when third-party developers and platform developers jointly possess a high level of security awareness can the “security wall” be raised higher and the cost for attackers be increased. Because the essence of security is a matter of cost.
As you can see, I have spent a lot of space explaining the security issues of OAuth 2.0 and specifically analyzing security awareness. This is to highlight the importance of security. And yes, it is also a key indicator of your ability to use OAuth 2.0 effectively.
Summary #
Alright, that’s the main content for today. I hope you can remember the following three points:
OAuth 2.0 is an authorization protocol that represents this authorization through access tokens. Once the third-party software obtains the access token, it can use the access token to access the user’s data on behalf of the user. Therefore, we say that the core of authorization is obtaining access tokens and using access tokens.
OAuth 2.0 is a secure protocol, but if not used properly, it cannot guarantee absolute security. If you do not implement it according to the recommendations in the OAuth 2.0 specification, there will be security risks. For example, not following the recommendation that authorization codes should only be used once, or that the redirect URL of third-party software should be an exact match.
The process of security protection has always been a “one-upmanship” process, with each side trying to outdo the other. Therefore, when using OAuth 2.0, both the third-party software and the platform should have sufficient security awareness to build a “secure wall” even higher.
Finally, I want to say that whether you use OAuth 2.0 to protect APIs or as the basis for user authentication, OAuth 2.0 is just a tool to solve these problems. Understanding the principles and use cases of OAuth 2.0 will help you solve these problems more efficiently and elegantly.
Thought-provoking Questions #
If you are a developer of third-party software, how do you think you should improve your awareness of security?
Feel free to share your thoughts in the comments section. You are also welcome to share today’s content with other friends for further discussion and exchange.