用户登录系统数据库表设计

最近看了看公司后台用户登录系统的设计， 比较混乱， 主要还是因为URS和Oauth以及URS第三方这三个登录形式各不相同导致的。

下面着重介绍一下涉及到第三方登录中需要注意的问题

在一个新项目中， 如果是要建立自己的登录体系的话， 那么直接创建一个Users表，包含username和password两列，这样，就可以实现登录了：

 id | username | password | name等其他字段
----+----------+----------+----------------A1 | bob      | a1b23f2c | ...A2 | adam     | c0932f32 | ...

如果要让用户通过第三方登录，比如微博登录或QQ登录，怎么集成进来呢？

以微博登录为例，由于微博使用OAuth2协议登录，所以，一个登录用户会包含他的微博身份的ID，一个Access Token用于代表该用户访问微博的API和一个过期时间。

要集成微博登录，很多童鞋立刻想到把Users表扩展几列，记录下微博的信息：

 id | username | password | weibo_id | weibo_access_token | weibo_expires | name等其他字段
----+----------+----------+----------+--------------------+---------------+----------------A1 | bob      | a1b23f2c | W-012345 | xxxxxxxxxx         | 604800        | ...A2 | adam     | c0932f32 | W-234567 | xxxxxxxxxx         | 604800        | ...

加一个QQ登录Users表就又需要加3列，非常不灵活

那么我们需要对这个表进行拆分。当用户以任意一种方式登录成功后，我们读取到的总是Users表对应的一行记录，它实际上是用户的个人资料（Profile），而登录过程只是为了认证用户（Authenticate），无论是本地用密码验证，还是委托第三方登录，这个过程本质上都是认证。

所以，如果把Profile和Authenticate分开，就十分容易理解了。Users表本身只存储用户的Profile， 其中ID为关联不同登录方式的外键。

 id | name | birth等其他字段
----+------+-----------------A1 | Bob  |  ...A2 | Adam | ...

而通过用户名口令登录可视为一种Authenticate的方式，利用LocalAuth表维护：

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

通过微博登录可视为另一种Authenticate方式，利用OAuth表维护， 但是access_token一般情况也只有几个小时的时效， 所以存储它是没有意义的， 每次登录的时候去微博后台验证一下客户端传来的token就行了。 如果用户只用了第三方登录， 那就拿第三方数据来填充刚才的User表即可。

 id | user_id | weibo_id |
----+---------+----------+11 | A1      | W-012345 |12 | A2      | W-234567 |

如果要添加另一种OAuth登录，比如QQ登录，那就再加一个列标示不同站点也就OK了， 但是要注意用户在不同登录方式的用户名和photo一般不一样， 所以也单独存起来

 id | user_id | oauth_name | oauth_id | nick_name| photo|
----+---------+------------+----------+----------+------+11 | A1      | weibo      | W-012345 | 12 | A2      | weibo      | W-234567 |13 | A1      | qq         | Q-090807 |14 | A2      | qq         | Q-807060 |

通过这种方式， 无论用户采用哪种方式登录， 都可以锁定到用户的user_id。

下面再说一下网易的URS登录， 因为我们要直接采用网易通行证， 所以也就不需自己存储密码， 因此我们的架构应该设为User表

 id | user_Email | username | birth
----+------------+----------+-----------01 | aa@126.com | bob      | 02 | bb@126.com | adam     | 

如果用户只用第三方登录， 显然无法填充user_Email这个字段， 因此userEmail可以为空。  如果第三方登录采用的是URS第三方的接口， 它返回的oauth_id 是aa@wx.163.com这种形式。 具体设计和上面也类似。 整体上使用这种方式比现在后台的逻辑要清晰很多