第三方登录

背景
虽然在界面上，第三方账号注册往往被称为“第三方账号登录”，但其实用户第一次使用第三方账号登录也是在创建一个新的账号。因此，我将第三方账号注册也算成是一种注册类型。  
第三方账号注册的好处是显而易见的：极致的简单和方便。但不利之处也非常明显：企业无法与用户之间产生任何连接，这对部分公司来说是完全无法接受的。  
对于第三方账号注册，几条优化建议是：
1.      第三方注册一般是和其他注册方式共存的。因此在设计上要注意分清主次。一般来说，第三方注册都是出于次要的位置。但也有部分APP将其作为主要注册方式，看需要。
2.      第三方注册成功后，不再要求用别的方式注册，否则就是一个骗子，用户会很不爽。还不如不用第三方呢。
3.      第三方注册成功后，如果还需要完善别的信息，则在需要这些信息时再要求用户填写，否则一个简单方便的注册就没有意义了。
 
授权登录实现
一．   简要概述
1.  先取第三方取access_token 和openid(uid)，openid是唯一的，表明用户身份的
2.  将openid和token传给服务器，服务器拿openid进行注册，并生成openid对应的密码
3.  当注册成功后服务器返回sessionid和对应密码
4.  将openid和对应密码加密后存在本地，本地需要记录的是:openid、对应密码、上一次登录时的登录方式.(qq登录、微信登录，微博登录，或者用户自己输入账号密码登录)
5.  客户端每次启动都登录，如果发现上一次登录方式是第三方登录，且此时本地存的openid有对应密码就将openid和对应密码传服务器进行登录。这样好处是客户端只走一次授权，将openid在自己公司服务器注册后以后就再也不走了(不再走指的是你项目不关闭，如果tokenid超时，此时不用和第三方再对接，而是直接拿本地的openid和对应密码进行登录，不会在项目使用过程中，跳到授权页)，当然取消授权，然后重新登录时要重新授权，此时还是会重新跳到授权页的，另外tokenid在有效时间内不会随着不同设备登录而改变，只有超时时才会重新产生新的tokenid，且过期时间根据最后一次登录重新计算。

二．   服务端实现
1.        数据库创建tb_user、tb_user_phone、tb_user_qq和tb_user_wx表；tb_user表就不详说了，这是基本表；tb_user_phone也不说了；重点说一下tb_user_qq和tb_user_wx表；这两个表各自储存对应的授权返回信息（请参考第三方授权返回）
2.        根据客户端的登录类型（type=1：手机 type=2：QQ  type=3：微信）取出对应的openid查询对应的表（如type=2，查询tb_user_qq是否有对应的信息），如果有，直接返回tb_user表的对应信息，如果没有，通知客户端未查询到对应的用户信息。
3.        根据客户端的注册类型（type=1：手机 type=2：QQ  type=3：微信）取出对应的授权信息存入对应的表（如type=2，直接存入tb_user_qq），并判断是否需要绑定手机号码，如果需要，则判断手机号码是否是已注册用户，如果是，直接把第三方账户绑定的手机号码对应的账户下，如果不存在，直接在tb_user表创建新用户，并绑定手机号码（不需要绑定手机号的情况就不多说了）。成功后返回用户信息。 4.        服务端应定时刷新用户的授权信息（已知微信的token是30天，具体的请参考第三方平台授权文档）。
三．   客户端实现
1.  客户端调起第三方授权SDK（请看第三方授权文档），获取授权信息； 2.  将授权信息发送给服务端执行登录，如果登录失败且原因是未查到此用户，则执行下面的操作（登录成功就没有什么好说的啦）。 3.  提示用户是否绑定手机号码，如果用户选择绑定则验证手机号码有效性（这里请参考手机号码验证文档），并带上手机号码和授权返回信息请求注册，如果用户选择不绑定，直接带上授权返回信息请求注册。
设想与问题
直接在tb_user表里加上QQ、weixin的type,openid和access_token字段,这种做法拓展性不好，以后要是再增加如：微博，淘宝等第三方登录的话，又要操作tb_user表，对tb_user表操作过于频繁容易出问题，而且也不是每一个用户都会使用第三方登录，会造成大量空缺字段，浪费。我之所以独立创建tb_user_*表也正是基于这些考虑的。