最近看了看公司后台用户登录系统的设计， 比较混乱， 主要还是因为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 | ……|
| :-------------- | :------------ :|:------------ :|:------------ :|:------------ :|:----------------:|:----------------:|
| 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 | a1b23f2c|
|02 | 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 | aa|bb|
|12 | A2 | weibo | W-234567 |aa|bb|
|13 | A1 | qq | Q-090807 |aa|bb|
|14 | A2 | qq | Q-807060 |aa|bb|
通过这种方式， 无论用户采用哪种方式登录， 都可以锁定到用户的user_id。
公司项目
下面再说一下网易的URS登录， 因为我们要直接采用网易通行证， 所以也就不需自己存储密码， 因此我们的架构应该设为User表
|id | user_Email | username | birth|
| :-------------- | :------------ :|:----------------:|
| 01 | aa@126.com | bob | 1|
| 02 | bb@126.com | adam | 1|
如果用户只用第三方登录， 显然无法填充user_Email这个字段， 因此userEmail可以为空。 如果第三方登录采用的是URS第三方的接口， 它返回的oauth_id 是aa@wx.163.com这种形式。 具体设计和上面也类似。 整体上使用这种方式比现在后台的逻辑要清晰很多
网友评论