[design]多认证方式的情况下如何设计帐号模型表

发表于 | 更新于 | 分类于

用户帐号登录表设计

当存在密码登录、第三方授权登录等登录方式的时候，系统的用户帐号模型应该如何设计？

1. 首先，这是一种思考方案

用户profile表一张，相当于用户总表

帐号密码登录，作为一种登录方式，搞一张表

OAuth作为一种登录方式，也建一张表；如果还有别的登录方式，也可以创建对应的认证表；

有些网站需要API访问，API可以使用api_key和api_secret来认证，可是怎么把一个API访问关联到一个用户？方法还是增加一种API Auth的表：

1
id | user_id | api_key  | api_secret

每一种X-Auth表都存储了用户的登录认证信息，并通过user_id关联到Users表。这样一来，不但登录过程简化了，而且一个用户可以使用多种方式登录。只要登录成功，拿到了user_id，最后读取Users表是为了获得用户的Profile

2. 另一种思路：

用户总表，含平台唯一uid；

每一个app，都注册登录过，会有对应的appuserid；

不同app通过一个和总表的关联表关联起来

1
2
3
4
5
本地用户唯一ID  社交网络类型  社交网络唯一ID
1112  weibo 20
5111  qq  20
6000  weixin  10
6000  qq  300

3. 目前第三方登录通常有两种设计思路

1、将第三方登录看成一种登录方式，使用第三方登录的前提是，你先要有一个账户。

缺点：当用户没有账户，直接使用第三方登录时，你只能提示他先去注册账户。但在用户看来，就是欺骗，容易引起用户的反感。

优点：当用户账户绑定了第三方账号后，用户就在也不用记住密码了，完全可以通过各个熟悉的第三方账号登录系统。

2、将第三方登录，看成一个独立的用户

优点：没有注册流程，容易吸引用户，由于是第三方直接登录，也不需要考虑用户会忘记密码

缺点：一个人容易产生多个账户，用户的行为容易分散到多个账户中，增加了系统的复杂性，某些情况下还会影响用户的产品体验。

通篇看下来，第三方登录并没有想象中的那么美好，第一种方式也就仅仅解决用户忘记密码的问题，注册时还会引起用户反感。第二种方式虽然能起到吸引用户的作用，但却增加了系统的复杂性，某些情况下还会影响用户的产品体验。

所以，大家可以根据自己的实际情况，考虑是否要添加第三方登录的支持，如果要，应该使用哪种第三方登录的模式。

4. user_auths表例子

1
2
3
4
5
6
7
8
9
user_auths


id             # 自增id
user_id        # users表对应的id
identity_type  # 身份类型（站内username 邮箱email 手机mobile 或者第三方的qq weibo weixin等等）
identifier     # 身份唯一标识（存储唯一标识，比如账号、邮箱、手机号、第三方获取的唯一标识等）
credential     # 授权凭证（比如密码 第三方登录的token等）
verified       # 是否已经验证（存储 1、0 来区分是否已经验证通过）