Maybe it’s easier to understand the principles of OAuth this way!

That year, the number of users of my company reached a new peak since the company was founded. After many programmers worked overtime day and night, each business system achieved a stability of almost four 9s. At the same time, the business also gained a certain degree of popularity in the industry.

[[282415]]
Image via Pexels

PS: The following business scenarios are only for Web systems, and the Web pages have background service programs.

That day, a partner suddenly came to visit us and proposed a win-win cooperation. The business scenario is that our system users can log in to their system and obtain certain user information in order to perform some business operations.

They want us to copy the existing user data into their system and update the newly registered users synchronously. Isn't this bullshit?...

[[282416]]

Why it doesn't work

In order to achieve user information interoperability and meet business requirements, there are actually many solutions. If it is not the bottom line, the solution of synchronizing user information is an amateur and a nonsense solution. Why do you say that?

First of all, let’s talk about the information synchronization method. If it is a one-way synchronization, the workload of all relevant personnel on both sides is already very large. Under certain conditions, if the one-way synchronization is upgraded to two-way information synchronization, the programmers on both sides will be miserable.

In addition, apart from the workload, user information is essentially the user's private information. If a user can safely store his or her privacy with you, it shows the trust in the company.

Once the operation of copying user information occurs, it is essentially irresponsible to the user, and is lacking both morally and legally.

Solution

As a technician, it is my duty to eliminate unreasonable solutions and provide technical solutions that are feasible for the business. So is there a low-level solution that does not require copying user information?

Assume that our company's system is A, the business domain name is www.A.com, the third-party system is B, and the business domain name is www.B.com.

Remember our ultimate business goal: to allow our company's users (system A) to log in to a third-party system (system B) and obtain some relevant information about the user. In extreme business situations, users in system A modify relevant information and synchronize it to system B.

Solution 1

At the login entrance of the third-party system, our users are allowed to enter their account and password, and then the third-party system (either the client or the server) uses the account and password entered by the user to request our company to log in to the server.

If the verification is successful, user-related information is returned. The third-party system receives the returned data, logs in according to its own login process, and can store user-related information.

The request format and general process are shown in the following figure:

 http://www.A.com/login?loginname=caicai&pwd=buzhidao

To be honest, I don’t recommend this solution. Although it is better than directly copying user information, it is still very problematic. Users have invisibly leaked their account passwords or other login credentials to an untrusted third-party system, which may not be the result the user wants.

Solution 2

The above solution has a fatal flaw, that is, the login page is a third-party page that users do not trust. If we can avoid such dangers and let users log in on a trusted website, it will greatly enhance users' trust.

It is very easy for us to implement login from a technical perspective. The only thing we need to consider is how to send user information to a third-party system after the user successfully logs in.

If we use the request call method (for example, if the login is successful, we call a third-party interface), it is technically feasible.

However, next time a third party applies for such a service, our calling interface may need to be modified. Therefore, the better and more common way in the industry now is to achieve it through address jump.

The specific process is as follows:

• When the user clicks "Log in" on a third party, he/she will be redirected to the login page provided by us. The URL of the page contains the address of the page to which the user will be redirected upon successful login, and the user will enter his/her account and password on this page.
• We determine the correctness of the user based on the user account and password, log in successfully, and obtain user information.
• Then jump to the successful login jump page provided by the third party and carry the user information over.
• The third-party jump page receives the user information, handles the remaining business, and the process ends.

In the first step, the third party redirects us to the login page URL as follows:

 http://www.A.com/login?type=userinfo&redirecturi=http://www.B.com/callback

Solution 3

The login part in Solution 2 is fundamentally different from Solution 1. Although it is only a change in the login method, the security and protection of user privacy are greatly improved.

However, there is still active transmission of user information in the process. If someone hijacks it, there is still a risk of user information leakage. How to avoid such risks?

Imagine, can other credentials be used to replace user information? Of course you can, and this is also a common way for modern Web systems to implement authorization.

User information is replaced by a token, and this token has a certain time limit and can only remain valid for a period of time, which protects the system data to a certain extent.

After the third-party system obtains this token, it will carry this token as a credential every time it obtains user information. Our system also only recognizes this token as an authorization credential.

 http://www.A.com/login?type=token&redirecturi=http://www.B.com/callback

Here I would like to mention that the token is issued through the front-end (browser) jump to the third-party system, and then the front-end of the third-party system transmits it to the back-end, and then the third-party back-end carries the token to obtain user information.

Please note that if a third-party front-end page carries a token to obtain user information, there is no security at all.

Solution 4

Solution 3 is actually sufficient in many cases, but one thing needs to be noted. Each token has a certain validity period. This is a design advantage, but it also means that if the token is obtained by others, user information can also be stolen.

Since the token is actually transmitted through the front-end (browser) in Solution 3, there is a risk of leakage whenever it is transmitted on the front-end. Is there any way to avoid transmission on the front-end?

One thing to remind you here is that in order to enable our users to log in to a third-party system and protect user privacy, logging in on our side is necessary.

Moreover, our system must issue a certificate to the third-party system in order to meet the third party's requirements for obtaining our users.

Since the transmission of credentials is inevitable, people have thought of transmitting a credential that is only valid once on the front end (browser), and then the third-party back end can obtain the token based on this credential, because the communication on the server side is much more secure than the communication on the front end (browser).

So plan 4 came into being:

• The user is redirected to our login page to log in.
• We verify that the user's username and password are correct, generate a code with a validity period of 1 and valid for a certain period of time, and carry this code to jump to the third-party callback page.
• The third-party callback page receives the Code parameter and transmits it to the back-end program.
• The third-party backend program receives the Code parameter and calls our interface with the Code.
• We verify the validity of the Code and return the token information if it is valid.
• The third party receives the token information and calls our interface with the token information to obtain user information.
• We verify the validity of the Token and return the user information if it is valid.
• Each subsequent call will carry the Token for access, and the Code will be useless even if someone obtains it.

 http://www.A.com/login?type=code&redirecturi=http://www.B.com/callback

Upgrade plan

Although Solution 4 seems good enough, it is not perfect. It is mainly manifested in the following points:

① When a third party jumps to our login page, we don’t know who this third party is or whether it is trustworthy, so it is necessary for us to identify whether this third party is trustworthy.

When we authorize a third party, we can issue each third party a data similar to appid and appkey. Appid is used to identify each third party authorized by us, and each appid must register the callback URL.

In this way, when a third party redirects to our login page, we can identify whether the third party and the callback redirect URL are valid.

② When a third party carries the Code to exchange for a Token, and every subsequent communication with the Token to obtain user information should be signed using the appid and appkey in accordance with our rules, so that our server can also identify whether the caller is trustworthy.

③On the user login authorization page, users can check the data content they authorize to a third party. These permissions will apply to the Code and token.

④Since each token has an expiration time, how to update the token will be a technical point. In fact, it is entirely possible to issue a token for updating the token at the same time as issuing the token. This token will be updated each time the token is reissued.

⑤ Every time our user's information is updated, the relevant token can be invalidated to allow the third party to re-acquire the user information and synchronize it.

⑥ Our login page and all interfaces for third-party calls should use the HTTPS protocol, and all third-party callback pages must also use HTTPS, which can effectively prevent malicious hijacking.

I don’t know if I have taught those students who are not clear about author2.0 authorization. If they are still not clear, please leave a message at the bottom to communicate.