用户数据表设计借鉴 浅谈数据库用户表结构设计，第三方登录 基于 Token 的身份验证

最近对用户数据表的设计比较感兴趣，看到了两篇比较好的文章。

浅谈数据库用户表结构设计，第三方登录

转载于： https://www.cnblogs.com/jiqing9006/p/5937733.html

这篇文章比较不错，很有借鉴和应用的价值

 

说起用户表，大概是每个应用/网站立项动工（码农们）考虑的第一件事情。用户表结构的设计，算是整个后台架构的基石。如果基石不稳，待到后面需求跟进了发现不能应付，回过头来反复修改用户表，要大大小小作改动的地方也不少。与其如此，不妨设计用户表之初就考虑可拓展性，争取不需要太多额外代价的情况下一步到位。

先前设计

id
username
password
用户名加上密码，解决简单需求，留个id作为其他表的外键。当然，那时候密码还可能是明文存储，好点的知道md5。

后来呢，随着业务需求的拓展，要加个用户状态 status 判断用户是否被封禁，注册时间和注册IP地址、上次登录时间和IP地址备查（并衍生出登录记录表，用来判断是否异地登录等，在此不表），用户角色/权限 role （又衍生出用户角色权限关系，还是另文讨论），业务也需要个人的个人信息如真实姓名、地址等也一股脑往上添加，现在形成了一个很完整的用户关系表。

id
username
password
realname
address
…
status
role
register_time
register_ip
login_time
login_ip
现在问题来了，进入Web2.0时代，微博开放了第三方网站登录，用微博帐号就能登录我们的网站，老板说，这个我们得要。加个微博用户登录表吧，当然，得和我们自己的用户表关联，这个微博用户信息表如下：

id 自增ID
user_id 关联本站用户ID
uid 微博唯一ID
access_token
access_expire
这还不算完，QQ又开放用户登录了，一下子要接入好多家第三方登录了，只能就着“微博用户信息表”继续加类型加判断，如果是每个第三方登录都新建一个表，肯定会疯的。

时代变了，进入了移动互联网时代，怎么也得支持个手机号登录吧？所以现在每家标配都是：用户名/邮箱/手机号登录，外加一系列微博、微信等第三方登录。表结构如下：

用户表
id
username
email
phone
…
用户第三方登录表
id
user_id
app_type
app_user_id
access_token
…
用户在输入框输入用户名/邮箱/手机号和密码之后，后台判断是邮箱、手机号或是用户名，再根据条件查询是否为特定用户。

这个表结构能够承载未来一段时间的业务需求了。如果说某天冒出了一个新的登录方式，比如身份证号登录，怎么办？继续在用户表加字段？我觉得有更好的选择。

改进版

无论username+password，还是phone+password，都是一种用户信息+密码的验证形式；再来理解第三方登录，其实它也是用户信息+密码的形式，用户信息即第三方系统中的ID（第三方登录一定会给一个在他们系统中的唯一标识），密码即access_token，只不过是一种有使用时效定期修改的密码。所以我们把它抽象出了用户基础信息表加上用户授权信息表的形式。

用户基础信息表 users
id
nickname
avatar
用户授权信息表 user_auths
id
user_id
identity_type 登录类型（手机号 邮箱 用户名）或第三方应用名称（微信 微博等）
identifier 标识（手机号 邮箱 用户名或第三方应用的唯一标识）
credential 密码凭证（站内的保存密码，站外的不保存或保存token）
这个系统最大的特色就是，用户信息表不保存任何密码，不保存任何登录信息（如用户名、手机号、邮箱），只留有昵称、头像等基础信息。所有和授权相关（且基本前端展示无关的），都放在用户信息授权表，用户信息表和用户授权表是一对多的关系。说起来太抽象，show me the code.

users
|id|nickname|avatar|
|1|慕容雪村|http://…/avatar.jpg|
|2|魔力鸟|http://…/avatar2.jpg|
|3|科比|http://…/avatar3.jpg|
user_auths
|id|user_id|identity_type|identifier|credential|
|1|1|email|[email protected]|password_hash(密码)|
|2|1|phone|13888888888|password_hash(密码)|
|3|1|weibo|微博UID|微博access_token|
|4|2|username|moliniao|password_hash(密码)|
|5|3|weixin|微信UserName|微信token|
说说具体处理，用户发来邮箱/用户名/手机号和密码请求登录的时候，依然是先判断类型，以某用户使用了手机号登录为例，使用 SELECT * FROM user_auths WHERE type=’phone’ and identifier=’手机号’ 查找条目，如有，取出并判断password_hash(密码)是否和该条目的credential相符，相符则通过验证，随后通过user_id获取用户信息。

如果使用第三方登录，则只要判断 SELECT * FROM user_auths WHERE type=’weixin’ and identifier=’微信UserName’ ，如果有记录，则直接登录成功，使用新的token更新原token。假设与微信服务器通信不被劫持的情况下无需判断凭证问题。

通过这个表结构设计，使许多原来纠结的问题瞬间解决，说说优点吧

一，站内登录类型无限拓展，代码改动小。如果真要支持身份证登录了，只要少许几处改动，无需修改表结构。

二，第三方登录类型可用工场模式批量拓展，新增第三方登录类型的开发成本降到最低。

三，原来条件下，应用需要验证手机号是否已验证和邮箱是否已验证，需要相对应多一个字段如 phone_verified 和 email_verified，如今只要在user_auths表中增加一个统一的verified字段，每种登录方式都可以直观看到是否已验证情况。基于信任第三方登录的数据准确性，默认第三方登录都是已验证。如果用户修改登录手机号或登录邮箱，也能清晰跟踪每一步的完成度。

四，可按需绑定任意数量的同类型登录方式，即一个用户可以绑定多个微信，可以有多个邮箱，可以有多个手机号，是不是很赞？当然你也可以限制一种登录方式只有一条记录。

五，在user_auths添加相应的时间和IP地址，就可以更加完整地跟踪用户的使用习惯，比如，已经不使用微博登录两年多，已经绑定微信300天

六，即使完全使用第三方帐号登录，可在前端做到“无需注册本站帐号”的效果。过去许多网站虽然支持第三方帐号登录，但出于留存用户等原因，第一次微博登录回来，让你再填写一套他们网站的邮箱、密码等信息，也就失去了微博登录的最大意义。从技术上说，原有的结构导致除了在微博用户表建立一个条目外，必须在用户表建立一条对应的条目，而且一般情况下不能让用户表里的邮箱或者用户名和密码留空。用户体验好的，邮箱自动生成 微博[email protected] ，密码则随机生成。至于体验不好的，只能说早知道还不如不用微博登录呢！现在呢，我们的这个用户表结构则完全没有这样的困扰，只要微博提供的昵称和头像地址就可以生成这个用户，再关联他的微博登录记录。而且我们的表结构意味着，用户可以解除他的所有登录方式，于是这个账户变彻底变成了没法登录的僵尸（解决办法是在代码里加一个限制，至少保留一条user_auths的记录）。如果你非得得到用户的邮箱，那么每次登录的时候看到他不存在一条identify_type为email的记录，则弹窗弹死他，让他赶快填邮箱，否则啥都别干。

七，提升了逻辑思维能力。抽象出事物本质是码农必备职业素养，通过对用户表结构的学习研究，提高了鄙人的各方面技能，从此写代码一路顺风顺水…

八，如果你说邮箱和手机号就是用户信息的组成部分，他们依然需要体现在users表中作为前端展示？没问题，users表尽管拓展，users表里依然有email,phone，但他们仅仅作为“展示用途”，和昵称、头像、或者性别这些属性没有本质区别。在用户信息表与用户授权登录拆分后，用户信息表可以随时增加任意字段，加星座，加生日，都没问题，只需要在前端展示时多几个输入框，录入时多几行代码，与用户登录相关的问题做到最大程度解耦。

有利必有弊，说说缺点。

一，原先的用户判断由1次SQL变成2次SQL请求。

二，用户同时存在邮箱、用户名、手机号等多种站内登录方式时，改密码时必须一起改，否则就变成了邮箱+新密码，手机号+旧密码访问了，肯定是很诡异的情况。如果考虑到这一点，又要在user_auths表中新增一个表示站内登录方式或第三方登录方式的标识字段。

三，代码量增加了，有些情况下逻辑判断增加了，难度增大了。举个例子，无论用户是否已登录，无论用户是否已注册过，都是点击同一链接前往微博第三方授权后返回，可能出现几种情况：1，该微博在本站未注册过，很好，直接给他注册关联并登录；2，该微博已经在本站存在，当前用户未登录，直接登录成功；3，该微博未在本站注册，但当前用户已经登录并关联的是另一个微博帐号，作何处理取决于是否允许绑定多个微博帐号；4，该微博未在本站注册过，当前用户已登录，尝试进行绑定操作；5，该微博已经注册，用户又已使用该帐号登录，为何他重复绑定自己- -. 6，该微博已经在本站存在，但当前用户已经登录并关联的是另一个微博帐号，作何处理？切换用户或是报错？（画一个流程图能更好描述这个问题）这个问题与采用的数据结构没有关系，只是在做第三方帐号注册登录时遇到的各种情况，在此一并整理。

 

另一篇是：基于 Token 的身份验证：JSON Web Token

转载于：https://ninghao.net/blog/2834

作者：王皓
发布于：2015-08-07 22:06
更新于：2018-06-15 20:52

最近了解下基于 Token 的身份验证，跟大伙分享下。很多大型网站也都在用，比如 Facebook，Twitter，Google+，Github 等等，比起传统的身份验证方法，Token 扩展性更强，也更安全点，非常适合用在 Web 应用或者移动应用上。Token 的中文有人翻译成 “令牌”，我觉得挺好，意思就是，你拿着这个令牌，才能过一些关卡。

文章先介绍了一下传统身份验证与基于 JWT 身份验证的方法，再理解一下 JWT 的 Token 的组成部分（头部，数据，签名），最后我们会在一个 Node.js 项目上实施签发与验证 JWT 的功能。练习的视频版本可以参考《JWT：JSON Web Token》这个免费的课程，项目代码在 Github 上可以找到。

宁皓网有一系列的基于 Token 身份验证的课程，比如在 Node.js 项目里，或者 WordPress 网站上实现这种身份验证的方法，我们还介绍了在小程序里面使用了这种基于 Token 的方法来验证小程序用户的身份。

订阅宁皓网以后，就可以在线学习所有这些基于 Token 验证身份的相关课程。

传统身份验证的方法

HTTP 是一种没有状态的协议，也就是它并不知道是谁是访问应用。这里我们把用户看成是客户端，客户端使用用户名还有密码通过了身份验证，不过下回这个客户端再发送请求时候，还得再验证一下。

解决的方法就是，当用户请求登录的时候，如果没有问题，我们在服务端生成一条记录，这个记录里可以说明一下登录的用户是谁，然后把这条记录的 ID 号发送给客户端，客户端收到以后把这个 ID 号存储在 Cookie 里，下次这个用户再向服务端发送请求的时候，可以带着这个 Cookie ，这样服务端会验证一个这个 Cookie 里的信息，看看能不能在服务端这里找到对应的记录，如果可以，说明用户已经通过了身份验证，就把用户请求的数据返回给客户端。

上面说的就是 Session，我们需要在服务端存储为登录的用户生成的 Session ，这些 Session 可能会存储在内存，磁盘，或者数据库里。我们可能需要在服务端定期的去清理过期的 Session 。

基于 Token 的身份验证方法

使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是这样的：

1. 客户端使用用户名跟密码请求登录
2. 服务端收到请求，去验证用户名与密码
3. 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
4. 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里
5. 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
6. 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据

JWT

实施 Token 验证的方法挺多的，还有一些标准方法，比如 JWT，读作：jot ，表示：JSON Web Tokens 。JWT 标准的 Token 有三个部分：

• header（头部）
• payload（数据）
• signature（签名）

中间用点分隔开，并且都会使用 Base64 编码，所以真正的 Token 看起来像这样：

eyJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc

Header

每个 JWT token 里面都有一个 header，也就是头部数据。里面包含了使用的算法，这个 JWT 是不是带签名的或者加密的。主要就是说明一下怎么处理这个 JWT token 。

头部里包含的东西可能会根据 JWT 的类型有所变化，比如一个加密的 JWT 里面要包含使用的加密的算法。唯一在头部里面要包含的是 alg 这个属性，如果是加密的 JWT，这个属性的值就是使用的签名或者解密用的算法。如果是未加密的 JWT，这个属性的值要设置成 none。

示例：

{
  "alg": "HS256"
}

意思是这个 JWT 用的算法是 HS256。上面的内容得用 base64url 的形式编码一下，所以就变成这样：

eyJhbGciOiJIUzI1NiJ9

Payload

Payload 里面是 Token 的具体内容，这些内容里面有一些是标准字段，你也可以添加其它需要的内容。下面是标准字段：

• iss：Issuer，发行者
• sub：Subject，主题
• aud：Audience，观众
• exp：Expiration time，过期时间
• nbf：Not before
• iat：Issued at，发行时间
• jti：JWT ID

比如下面这个 Payload ，用到了 iss 发行人，还有 exp 过期时间这两个标准字段。另外还有两个自定义的字段，一个是 name ，还有一个是 admin 。

{
 "iss": "ninghao.net",
 "exp": "1438955445",
 "name": "wanghao",
 "admin": true
}

使用 base64url 编码以后就变成了这个样子：

eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ

Signature

JWT 的最后一部分是 Signature ，这部分内容有三个部分，先是用 Base64 编码的 header.payload ，再用加密算法加密一下，加密的时候要放进去一个 Secret ，这个相当于是一个密码，这个密码秘密地存储在服务端。

• header
• payload
• secret

const encodedString = base64UrlEncode(header) + "." + base64UrlEncode(payload); 
HMACSHA256(encodedString, 'secret');

处理完成以后看起来像这样：

SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc

最后这个在服务端生成并且要发送给客户端的 Token 看起来像这样：

eyJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc

客户端收到这个 Token 以后把它存储下来，下回向服务端发送请求的时候就带着这个 Token 。服务端收到这个 Token ，然后进行验证，通过以后就会返回给客户端想要的资源。

签发与验证 JWT

在应用里实施使用基于 JWT 这种 Token 的身份验证方法，你可以先去找一个签发与验证 JWT 的功能包。无论你的后端应用使用的是什么样的程序语言，系统，或者框架，你应该都可以找到提供类似功能的包。

下面我们在一个 Node.js 项目里，用最简单的方式来演示一下签发还有验证 JWT 的方法。练习有个视频版本，你可以参考《 JWT：JSON Web Token 》这个免费的视频课程。

项目代码：https://github.com/ninghao/jwt-demo

准备项目

准备一个简单的 Node.js 项目：

cd ~/desktop
mkdir jwt-demo
cd jwt-demo
npm init -y

安装签发与验证 JWT 的功能包，我用的叫 jsonwebtoken，在项目里安装一下这个包：

npm install jsonwebtoken --save

签发 JWT

在项目里随便添加一个 .js 文件，比如 index.js，在文件里添加下面这些代码：

const jwt = require('jsonwebtoken')

// Token 数据
const payload = {
  name: 'wanghao',
  admin: true
}

// 密钥
const secret = 'ILOVENINGHAO'

// 签发 Token
const token = jwt.sign(payload, secret, { expiresIn: '1day' })

// 输出签发的 Token
console.log(token)

非常简单，就是用了刚刚为项目安装的 jsonwebtoken 里面提供的 jwt.sign 功能，去签发一个 token。这个 sign 方法需要三个参数：

1. playload：签发的 token 里面要包含的一些数据。
2. secret：签发 token 用的密钥，在验证 token 的时候同样需要用到这个密钥。
3. options：一些其它的选项。

在命令行下面，用 node 命令，执行一下项目里的 index.js 这个文件（node index.js），会输出应用签发的 token：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlLCJpYXQiOjE1MjkwMzM5MDYsImV4cCI6MTUyOTEyMDMwNn0.DctA2QlUCrM6wLWkIO78wBVN0NLpjoIq4T5B_2WJ-PU

上面的 Token 内容并没有加密，所以如果用一些 JWT 解码功能，可以看到 Token 里面包含的内容，内容由三个部分组成，像这样：

// header
{
  "alg": "HS256", 
  "typ": "JWT"
}

// payload
{
  "admin": true, 
  "iat": 1529033906, 
  "name": "wanghao", 
  "exp": 1529120306
}

// signature
DctA2QlUCrM6wLWkIO78wBVN0NLpjoIq4T5B_2WJ-PU

假设用户通过了某种身份验证，你就可以使用上面的签发 Token 的功能为用户签发一个 Token。一般在客户端那里会把它保存在 Cookie 或 LocalStorage 里面。

用户下次向我们的应用请求受保护的资源的时候，可以在请求里带着我们给它签发的这个 Token，后端应用收到请求，检查签名，如果验证通过确定这个 Token 是我们自己签发的，那就可以为用户响应回他需要的资源。

验证 JWT

验证 JWT 的用效性，确定一下用户的 JWT 是我们自己签发的，首先要得到用户的这个 JWT Token，然后用 jwt.verify这个方法去做一下验证。这个方法是 Node.js 的 jsonwebtoken 这个包里提供的，在其它的应用框架或者系统里，你可能会找到类似的方法来验证 JWT。

打开项目的 index.js 文件，里面添加几行代码：

// 验证 Token
jwt.verify(token, 'bad secret', (error, decoded) => {
  if (error) {
    console.log(error.message)
    return
  }
  console.log(decoded)
})

把要验证的 Token 数据，还有签发这个 Token 的时候用的那个密钥告诉 verify 这个方法，在一个回调里面有两个参数，error 表示错误，decoded 是解码之后的 Token 数据。

执行：

node ~/desktop/jwt-demo/index.js

输出：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlLCJpYXQiOjE1MjkwMzQ3MzMsImV4cCI6MTUyOTEyMTEzM30.swXojmu7VimFu3BoIgAxxpmm2J05dvD0HT3yu10vuqU

invalid signature

注意输出了一个 invalid signature ，表示 Token 里的签名不对，这是因为我们组长 verify 方法提供的密钥并不是签发 Token 的时候用的那个密钥。这样修改一下：

jwt.verify(token, secret, (error, decoded) => { ...

再次运行，会输出类似的数据：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlLCJpYXQiOjE1MjkwMzUzODYsImV4cCI6MTUyOTEyMTc4Nn0.mkNrt4TfcfmP22xd3C_GQn8qnUmlB39dKT9SpIBTBGI

{ name: 'wanghao', admin: true, iat: 1529035386, exp: 1529121786 }

RS256 算法

默认签发还有验证 Token 的时候用的是 HS256 算法，这种算法需要一个密钥（密码）。我们还可以使用 RS256 算法签发与验证 JWT。这种方法可以让我们分离开签发与验证，签发时需要用一个密钥，验证时使用公钥，也就是有公钥的地方只能做验证，但不能签发 JWT。

在项目下面创建一个新的目录，里面可以存储即将生成的密钥与公钥文件。

cd ~/desktop/jwt-demo
mkdir config
cd config

密钥

先生成一个密钥文件：

ssh-keygen -t rsa -b 2048 -f private.key

公钥

基于上面生成的密钥，再去创建一个对应的公钥：

openssl rsa -in private.key -pubout -outform PEM -out public.key

签发 JWT（RS256 算法）

用 RS256 算法签发 JWT 的时候，需要从文件系统上读取创建的密钥文件里的内容。

const fs = require('fs')

// 获取签发 JWT 时需要用的密钥
const privateKey = fs.readFileSync('./config/private.key')

签发仍然使用 jwt.sign 方法，只不过在选项参数里特别说明一下使用的算法是 RS256：

// 签发 Token
const tokenRS256 = jwt.sign(payload, privateKey, { algorithm: 'RS256' })

// 输出签发的 Token
console.log('RS256 算法：', tokenRS256)

验证 JWT（RS256 算法）

验证使用 RS256 算法签发的 JWT，需要在文件系统上读取公钥文件里的内容。然后用 jwt 的 verify 方法去做验证。

// 获取验证 JWT 时需要用的公钥
const publicKey = fs.readFileSync('./config/public.key')

// 验证 Token
jwt.verify(tokenRS256, publicKey, (error, decoded) => {
  if (error) {
    console.log(error.message)
    return
  }
  console.log(decoded)
})