A simple explanation of OAuth 2.0
OAuth 2.0 is currently the most popular authorization mechanism, used to authorize third-party applications to obtain user data.
This standard is relatively abstract and uses a lot of terminology, making it difficult for beginners to understand. In fact, it is not complicated to say. Let me use a simple analogy to help you easily understand what OAuth 2.0 is.
1. Courier problem
I live in a large residential complex.
The community has an access control system.
You need to enter a password when entering.
I often shop online and take out food, and couriers come to deliver it every day. I have to find a way to let the courier enter the community through the access control system.
If I tell the courier my password, he will have the same permissions as me, which seems inappropriate. If I want to cancel his right to enter the community, it will be very troublesome. I will have to change my own password and notify other couriers.
Is there a way for the courier to enter the community freely without knowing the password of the community residents? Moreover, his only authority is delivery, and he does not have authority for other occasions that require passwords?
2. Design of authorization mechanism
So, I designed an authorization mechanism.
The first step is to add a button called "Get Authorization" under the password input device of the access control system. The courier needs to press this button first to apply for authorization.
In the second step, after he presses the button, a dialog box will pop up on the phone of the owner (that is, me): Someone is requesting authorization. The system will also display the courier's name, job number and courier company.
I confirmed that the request was true and clicked the button to tell the access control system that I agreed to grant him authorization to enter the community.
In the third step, after the access control system receives my confirmation, it will display an access token to the courier to enter the community. A token is a string of numbers similar to a password, which is only valid for a short period of time (such as seven days).
In the fourth step, the courier enters the token into the access control system and enters the community.
Someone may ask, why not open the door for the courier remotely, but generate a separate token for him? This is because the courier may come to deliver the goods every day, and he can reuse the token the next day. In addition, some communities have multiple access controls, and couriers can use the same token to pass through them.
3. Internet Scene
Let’s move the above example to the Internet, which is the design of OAuth.
First of all, residential communities are network services that store user data. For example, WeChat stores my friend information. To obtain this information, you must go through WeChat's "access control system".
Secondly, the courier (or courier company) is a third-party application that wants to pass through the access control system and enter the community.
Finally, I am the user myself and agree to authorize third-party applications to enter the community and obtain my data.
Simply put, OAuth is an authorization mechanism. The owner of the data tells the system that he agrees to authorize third-party applications to enter the system and obtain this data. The system then generates a short-term access token (token), which is used in place of a password and can be used by third-party applications.
4. Token and Password
Token and password have the same function, and they can both enter the system, but there are three differences.
(1) The token is short-term and will automatically expire when it expires and cannot be modified by the user. Passwords are generally valid for a long time and will not change if the user does not modify them.
(2) The token can be revoked by the data owner and will become invalid immediately. In the above example, the homeowner can cancel the courier's token at any time. Passwords are generally not allowed to be revoked by others.
(3) The token has a scope of authority, for example, it can only enter the second door of the community. For network services, read-only tokens are more secure than read-write tokens. The password is generally for full access.
The above designs ensure that the token can allow third-party applications to obtain permissions, while at the same time being controllable at any time without endangering system security. This is the beauty of OAuth 2.0.
Note that as long as you know the token, you can enter the system. The system generally does not confirm the identity again, so the token must be kept secret. The consequences of leaking the token are the same as leaking the password. This is why the validity period of the token is generally set very short.
OAuth 2.0 is very specific about how tokens are issued. Specifically, it is divided into four authorization types (authorization grant), that is, four ways of issuing tokens, which are suitable for different Internet scenarios. In the next article, I will introduce these four types and give code examples.
(over)