[Big front-end account system connection] How should passport be implemented ?, Account passport

[Big front-end account system connection] How should passport be implemented ?, Account passport
Preface

I wrote a blog for research when I accessed the Baidu Account System: [big front-end] I learned about single-point logon and found that many small companies did not actually connect their account systems, to sum up, the reason why the account system fails is:

① At the beginning, I never thought that identity authentication should be integrated.

② In the subsequent business, too many login systems were found, but due to business pressure and complexity of integration, they were shelved.

This is the technical debt. The technical debt of this basic service is not timely, which may lead to engineering problems that cannot be ignored:

① More and more account system related requirements (login, registration, personal information management ......), every time you need to re-do

② User data does not have a receiver. It is difficult to integrate and analyze the data volume together (for example, some systems use accounts to log on, and some systems use mobile phones to log on, if you want to convert all of them to login via mobile phones, it will be hard to do)

③ The Account System is disconnected (all applications need to share an Identity Authentication System), which may cause channel failure. For example, in most cases, the wallet is also an independent channel, and after a subchannel generates an order, you need to go to the wallet channel to complete the payment (http --> https). If you need to log on again, this is a very bad behavior.

To solve the preceding problems, you must connect to the account system. There are two necessary conditions:

① All application systems depend directly on the same identity authentication system

② All subsystems must be transformed and certified by the above authentication system. That is, as mentioned in the previous article, ticket must be recognized.

Then, the real situation is disappointing. Many subsystems have been isolated from each other and their databases are inconsistent. So more often, we have the following problems:

① How to connect the Account System

② How to connect new businesses to the Account System

③ How old businesses access the account system

④ What should H5 do?

⑤ What should Native do?

⑥ No time (unconscious)

The content in this article is self-knowledge summary, and I am the front-end. If the text is incorrect, please point it out.

User data sharing

The premise of achieving Account System Interconnection is user data sharing. Scattered user management is a obstacle to Account System Interconnection. User data cannot be shared and there is no connection between systems, therefore, to strictly create independent users for sub-businesses, all the company's systems must rely on the same user information table. This table does not contain any business and may contain the following data:

① User ID

② User nickname

③ User's mobile phone

④ User Password

⑤ Avatar & Gender & Date of Birth & ID Card & Avatar ......

In poor cases, the login registration of each subsystem is completely independent, so that the user forms an information island. migrating the user public information of each subsystem to a table is the first step.

PS: this situation where subsystems are independent may even have duplicate mobile phone numbers in the User table.

Differentiated Processing

If all subsystems share the same user table, the first problem will be solved immediately. How can we differentiate them? For example:

① Sub-system A users have role permissions, such as administrators, visitors, and super administrators.

② Sub-system B users are used for hospital roles and have professional titles. They are professors, associate professors, and lecturers.

③ Subsystem C is a hospital with attributes such as address and top 3.

In this case, each subsystem needs to maintain a User Role table, for example:

1 // user summary table 2 // company users are not necessarily subsystem users, but subsystem users must exist with 3 var users = [4 {5 id in the company user summary table: '1', 6 phone: '000000', 7 name: 'nickname 1', 8 infos: 'Other public information' 9}, 10 {11 id: '2 ', 12 phone: '123', 13 name: 'nickname 2', 14 infos: 'Other public information' 15}, 16 {17 id: '3', 18 phone: '123', 19 name: 'nickname 3', 20 infos: 'Other public information' 21} 22]; 23 // User table 24 var a_users = [25 {26 id: '1', 27 roleId: '1' // visitor 28}, 29 {30 id: '3', 31 roleId: '2' // super administrator 32} 33]; 34 // User table 35 var B _users = [36 {37 id: '1', 38 title: 'Professor '// visitor 39}, 40 {41 id: '2', 42 roleId: 'associate Professor' // super administrator 43} 44]; 45 // User table 46 var c_users = [47 {48 id: '2', 49 address: 'xxxx', 50 title: '3pa' // visitor 51}, 52 {53 id: '3', 54 address: 'xxxx', 55 roleId: 'dimethyl '// super administrator 56} 57];

At this time, different systems can be differentiated. One of the worst cases is that the previous sub-system user table already contains business information such as roleId, which makes separation quite annoying.

Many of my friends don't pay attention to the three paradigms of database design, but they can realize the benefits of the third paradigm when they encounter problems!

After the user data is interconnected, you can proceed to the next step !!!

Unified Authentication System

All passport systems (Unified logon authentication system) have two core functions:

① Login

② Authorization or authentication

PS: because all applications of our team are in the same primary domain for the time being, cross-origin is not considered for the time being.

The Implementation Scheme here is as follows:

① Subsystem (a.domain.com) accesses the interface to be logged on. If you are not logged on, you will be redirected to the unified logon page (passport.domain.com)

② After the user logs on, the server writes ticket to the Primary Domain cookie and jumps back to subsystem a.domain.com.

③ Subsystem a.domain.com access interface. If the server finds that it has a ticket, it will go to the passport server for verification. If the verification succeeds, it will be returned to the subsystem server user ID.

④ The subsystem writes cookies to its own domain name and does not apply passport authentication during the validity period

Similarly, if the subsystem B .domain.com is running the system, because ticket already exists in the primary domain, it will directly access the Business System of a and obtain permission control and other information related to the business system.

For example, you can call the getInfo interface to obtain basic information:

① Because the interface requires logon status, log on to passport first.

② After logging on to passport, enter the flag ticket in the cookie type in the primary domain and re-jump back to the subsystem.

③ When the subsystem accesses the getInfo interface and finds that the primary domain has a ticket flag, the system uses this flag for passport verification. If the verification succeeds, user information is returned.

④ The subsystem filters out more information based on the basic user information with the user ID, such as the roleId, and returns it to the front-end H5 page

This is a unified authentication system, and the key to being easily ignored is:

The subsystem obtains the ticket in the primary domain and verifies the validity by passport.

Each subsystem must be able to identify the ticket of the passport mechanism, meaning that each subsystem must be connected to the passport

The access method is actually very simple. It can be completed in several steps, for example:

① The passport side provides an interface, getUserInfo. If the primary domain has cookie information, the user information will be returned. If not, the error code will be returned (not logged on)

② If the business system needs to log on to the service system, the server directly uses ticket to get the user information for the first time. If the information is obtained, the server stores the session locally. If not, the server directly returns the passport error code.

③ If the business system obtains user information, it can make simple packaging by itself, or do nothing, depending on the business needs.

Conclusion logon logout

To log out, it is actually relatively simple. To change the judgment rules of each business system, ticket must be in place to check whether the session of the system exists, you can directly call the logout interface of passport to delete the primary domain ticket.

About APP and H5 Authentication

In more cases, the APP uses Webview to open the H5 page. To handle the login status, the App needs to request the passport interface and save ticket, when webview is opened, ticket can be directly injected into the main domain.

Of course, the premise here is that the subsystem has been connected to passport.

Cross-origin is not involved because the actual work is not involved for the time being. The knowledge points here may be modified based on the subsequent access level.

For a simple implementation of the Code, please refer to this article: http://www.cnblogs.com/yexiaochai/p/4422460.html.