Assuming that our system login needs to be authorized with customer information, we need to know if an email is an employee of the customer.

The customer provides an account of the employee table, through which we can read the following data table

. email phone password .
[email protected] 1882375662 4b3e3c2f99046f9
[email protected] 1726639880 d0cd2693b35066
[email protected] 1783305223 e55f86a1f9e06e5

The customer set this account to read-only to prevent us from accidentally modifying the employee table information.

Through the above table, we can compare user email with email in the above table to achieve verification.

When a user uses our system, he/she will enter his/her email in the input box of our login page. After receiving the email of the user, we will compare the email provided by the user with the email in the customer database and enter the system after successful verification.

The system runs smoothly for three months.

The customer said, this way we can go through the employee list, we can get the composition of the employees in their company.

So we contacted the customer and switched to the second option.

The customer provides a method

(email) => boolean
Copy the code

This method is exposed as the interface that we call to verify that the user’s email is correct. In this way, we cannot read all the emails of the client company.

But we can request this interface with a bunch of made-up emails, and guess the employee composition of the client’s company by looking at whether the person returned is an employee of our company. With this in mind, the client designed the interface with an interface call limit of 200 requests per day, which prevented us from using the interface to try out the email of the client’s employees and get their employee composition information.

The system runs smoothly for three months.

We found that we could quickly guess the employee composition of a client’s company without making up a bunch of email addresses to request authentication interfaces. Every time a user uses our system, he/she needs to enter a valid customer company email verification. If we record users’ emails, over time, we can still get information about the employee composition of the client’s company.

That is, user accounts cannot flow through our system.

Therefore, we proposed that after our front-end page got the user account, it would first carry out MD5 encryption, and then transmit the encryption to our system. We would send MD5 to the customer, and the customer would make comparison and return to us whether the account belongs to the customer’s organization.

So if we store it, it’s a bunch of MD5’s, and we can’t reverse what emails the user’s organization has.

The system runs smoothly for three months.

The customer said that even if we promised them that we would immediately convert the user’s input account into MD5 into our system after we got it on the front page, we could not guarantee that we would not collect the account in the future.

In order to meet the needs of customers, we need that users’ accounts should not appear in any part of our system, including the input box of the front end.

That is to say, for customers, users cannot enter their account numbers in our input box.

At the same time, for us, we need a piece of information to identify the user’s account number, and this information we can’t decrypt the valid information.

Users cannot enter their account numbers in our input box, so they must only enter their account numbers in the customer’s page.

We need a message that identifies the user’s information, but we can’t decrypt it.

And here we also have an input box, the original input is the user account, now the input is encrypted information.

So the process could be

  1. A user visits a customer’s website and enters an account number
  2. The client website returns a string of MD5’s
  3. Users copy and paste MD5 into the original account input box on our website
  4. The user clicks login, we send MD5 to the client authentication interface, and the authentication successfully enters our system

There is a problem here, that is, the user needs to use our website at this time, but needs to open the customer’s address, so you can add a step:

  1. Users visit our website, and our website redirects to the customer’s website
  2. The user enters an account number on the customer’s website
  3. The client website returns a string of MD5’s
  4. Users copy and paste MD5 into the original account input box on our website
  5. The user clicks login, we send MD5 to the client authentication interface, and the authentication successfully enters our system

Here is a place that can be automated: the client website can return MD5 to our website, so it can be changed to:

  1. Users visit our website, and our website redirects to the customer’s website
  2. The user enters the account in the input box of the customer’s website. After the customer’s website is authenticated successfully, the user redirects to our website with MD5
  3. Our website will send MD5 to the customer’s website for authentication, and enter our system after successful verification

For us, the solution is that all we pass is a string that we can’t decrypt, which solves the problem of hot user information. For customers, email only flows in their own system and will not be leaked. Some information contained in email itself will not be known to the outside world. For users, the original login step is to enter email in our system and click login to enter our system. Now, when you log in to our system, our system will jump to another page. After entering your account number on that page, you will click Authorization and jump back to our web page and then enter our system.

The actual OAuth adds some extra fields or steps to accommodate insecure network environments, and the core principle is the same.