How to Design User logon and User Logon

How to Design User logon and User Logon

In the Web system, user logon is the most basic function. To achieve user name + password login, many people's first thought is to directly create a Users table, which contains the username and password columns. In this way, you can achieve login:

Id | username | password | other fields such as name ---- + ---------- + ---------------- A1 | bob | a1b23f2c |... A2 | adam | c0932f32 |...

Now, the question is, how can we integrate a third-party login, such as Weibo login or QQ login?

Take Weibo logon as an example. Because Weibo uses the oau2protocol to log on, a login user will contain the ID of his Weibo identity, an Access Token is used to represent the API used by the user to Access Weibo and the expiration time.

To integrate Weibo login, many kids shoes immediately want to extend the Users table to several columns to record Weibo information:

Id | username | password | weibo_id | others | other fields such as name ---- + ---------- + others + ----------------- + -------------- A1 | bob | a1b23f2c | W-012345 | xxxxxxxxxx | 604800 |... a2 | adam | c0932f32 | W-234567 | xxxxxxxxxx | 604800 |...

Add a QQ account to log on to the Users table and add three more columns. If this extension is performed, the tables will be exhausted. do not maintain the code.

So how can we design a flexible login?

Consider user logon from another perspective. After a user successfully logs on to the Users table in any way, we read a row of records corresponding to the Users table, which is actually the user's Profile ), the login process is only for authentication of users (Authenticate). Whether it is a local password verification or a third-party login, this process is essentially authentication.

Therefore, it is easy to understand the separation of Profile and Authenticate. The Users table itself only stores the user's Profile:

Id | name | other fields such as birth ---- + ------ + ----------------- A1 | Bob |... A2 | Adam |...

Logon using the username and password can be viewed as an Authenticate method, which is maintained using the LocalAuth table:

 id | user_id | username | password----+---------+----------+----------- 01 | A1      | bob      | a1b23f2c 02 | A2      | adam     | c0932f32

Log on Via Weibo is considered as another Authenticate Method, which is maintained using the OAuth table:

 id | user_id | weibo_id | weibo_access_token | weibo_expires----+---------+----------+--------------------+--------------- 11 | A1      | W-012345 | xxxxxxxxxx         | 604800 12 | A2      | W-234567 | xxxxxxxxxx         | 604800

If you want to add another OAuth login type, such as QQ login, you can add a table. However, since everyone belongs to the OAuth family, it is better to unify it into a single table and separate the names of each table:

 id | user_id | oauth_name | oauth_id | oauth_access_token | oauth_expires----+---------+------------+----------+--------------------+--------------- 11 | A1      | weibo      | W-012345 | xxxxxxxxxx         | 604800 12 | A2      | weibo      | W-234567 | xxxxxxxxxx         | 604800 13 | A1      | qq         | Q-090807 | xxx-xxx-xxx        | 86400 14 | A2      | qq         | Q-807060 | xxx-xxx-xxx        | 86400

If you want to add a new Login method, such as SAML, then add a table of this type.

Each X-Auth table stores user login authentication information and associates it with the Users table through user_id. In this way, the login process is simplified, and a user can log on in multiple ways. As long as the logon succeeds, get the user_id and finally read the Users table to get the user's Profile. In this way, the read data is more secure because the Users table does not contain the user password, the password is not accidentally disclosed because the API is exposed.

Personal Website: http://www.51pansou.com
. Net video download:. net video tutorial
. Net source code download:. net source code