[featured] how do you design unified login with multiple accounts?

Unified login of multiple accounts

Explanation of the name

The multi account here is different from the system level , When we talk about multi account system, we mean , In our Internet applications , Our app will use multiple third-party accounts to log in , For example, the common APP： NetEase 、 WeChat 、QQ wait .

Content

Through this article ：

• Can learn ： The details of technical solutions for multiple users , And the corresponding table design , Process design .

• You can't learn ： Like any other article , I won't have specific code implementation details here , The plan is right , How to write the code

Architecture evolution

Initial stage of entrepreneurship

It comes down to the fact that the number of users is relatively small at this time , I haven't even connected to the account system of other third parties mentioned above , Just a self built system can satisfy , If we build our own system , At present, there are

User name password registration login

This method will be used in many initial website construction , To register first , Log in again , In the older cms This shadow can be found in .

flow chart ：

Process description ：

• The front end will be user name 、 Password sent to server , The server makes regular judgments , Judge user name 、 Whether the password length meets , Whether the user name is repeated or not , The condition does not directly return the corresponding error code to the front end , Here is the password field , In order to prevent the transmission process is truncated , It is recommended to encrypt and upload again , By default, our transmission password will have one md5 encryption , Then record to the database for another layer of encryption , Even if it's out of storage, it's ok , Don't store passwords in plain text .

• After the verification is passed , Just write the username and password to the database , And carry out the operation of the back points distribution, etc , Not here .

• Now log in , The front end will be user name , The password is sent to the server , The server will first verify whether the number of logins exceeds the set threshold , If you exceed, you can only wait for the house to be closed .

• If the login logic is not exceeded , Judge user name 、 Is the password correct , If the password is incorrect, the threshold value will be determined , If it's over, close the darkroom , Remember that black houses have to have expiration dates , Or it will be permanently closed , This can be used redis Do it when it's overdue .

• After successful login, all subsequent post logics will be performed , For example, add points ... Wait for the operation .

Mobile number registration login

flow chart ：

Process description ：

• First, enter the mobile number , Then send it to the server , The server records the mobile number in our database , Then generate random verification code , And bind the mobile number and verification code to a redis Inside , Then record the expiration date , This expiration date is usually 10 About minutes , This is the validity period of our general mobile phone verification code .

• When the mobile phone receives the SMS , Then fill in the verification code in the interface and send it to the server , After the server receives the verification code, it will be in redis Check the verification code corresponding to the mobile phone number , If it fails, it will return the error code .

• Log in after success .

There doesn't seem to be a clear sign in operation , In fact, sending mobile phone number can be considered as a regular registration , Then the verification code input is a login operation ,

ask ： What do I do with the password ？

answer ： Add one to the follow-up product   Mobile phone number password supplement function   that will do , It's a very conventional technique now , But now in the era of mobile Internet explosion , Passwords are not that important anymore , Anyway, I never remember the code , If the phone number can be operated app, Never use a password to operate .

Database design

Table structure ：

Self increasing ID	user name	password	cell-phone number	Wrong number
1	user1	7fef6171469e80d32c0559f88b377245	13456789012	0
2	user2	7fef6171469e80d32c0559f88b377245	13456789013	0

explain ：

Here is just the data needed , There is no extension of specific scenarios , This table structure can satisfy the design of the above two schemes .

Introduce third party account scheme

Here is to QQ-SDK Login logic , Let's start with a sequence diagram

explain ：

• The client calls up the login interface , Enter the user name 、 password , Here is the user name of the third party , password , After successful login , Returns the access_token openid expire_in, This process will use oauth2.0, But in the sdk The built-in callback gets , Later we will explain what we have achieved oauth2.0

• The client gets access_token、openid、login_type（qq、wechat...） Request application server , After the application server gets these data, it will follow the corresponding login_type Go to the corresponding user center access_token and openid check . If the verification fails, the corresponding error code will be returned

• After passing the verification, it will determine whether there is this in the local area login_type and openid Whether there is , If it doesn't exist, get the remote user name 、 Basic information such as avatars is used as local basic data , And back to code value

• If it already exists , That is to log in , return code value .

• The client gets code After value token Value in exchange for , This is in full compliance with oauth2.0 The agreement came and went , Every subsequent request must be accompanied by token,token It takes a long time to be on the server , Because what we want to do is the kind of operation that never goes offline , So every time we ask, we will token The expiration time is accumulated .

Database design

According to the suggestions of some of our partners , I'm here to do some database sorting ：

User base table （users）

Field	remarks
user_id	user id
token	Users log in token
expire_in	token Expiration time
try_times	Number of login failures

User authentication association table （user_auth_rel）

Field	remarks
id	Self increasing id
user_id	user id
auth_id	Validation form id
auth_type	Verification type (local、third)

Local user table （user_local_auth）

Field	remarks
auth_id	authentication id, Self increasing id
user_name	User unique identification
password	User password
mobile	User's mobile phone

Third party user list （user_third_auth）

Field	remarks
auth_id	user id
openid	Third party user unique ID
login_type	Third party platform logo (qq、wechat...)
access_token	Acquired by a third party access_token, Verification use

explain

• users The table is only for the login of our business side , Mainly do their own business oauth2.0 Business

• user_local_auth Make your own user name 、 Password to login , Mobile number login information record ,

• user_third_auth It is the data record of our third-party user system ,

• user_auth_rel It's used to connect us users Table and user_local_auth、user_third_auth.

• The whole design concept is to distinguish self built users from third parties in storage , This also makes sense in the evolution of Architecture , At the beginning, most user systems were built by themselves , Then it's external access .

summary

In general , The access technology of the third-party users is relatively simple , There is one more design here user_thirds It can support enough third-party access , Of course, we usually log in two or three times , Too many logins are not only self maintenance costs , The interface doesn't look good, either .

I hope you can learn from the above , Be able to have a better understanding of our multi account login , Here the design does not include sub table sub database 、 No service , It's simple and direct design , Of course, the number of users is not the same as what they need , On this basis, we need to add a lot of things , Thank you for reading ！