用户验证方案

一、使用HTTPS 协议

HTTPS 协议：是“HTTP协议” 和 “SSL/TLS协议”的组合。HTTP的安全版。其实就是一个安全通信通道，基于HTTP开发，用于在客户计算机和APP后台之间交换信息。使用安全套接字层进行信息交换。

SSL（1999年之前）：安全套接层       TLS（1999年SSL协议标准化之后）:传输层安全协议  两者可以视为同一个东西的不同阶段

二、基本的用户登录方案

传统Web网站使用Cookie+Session保持用户的登录状态

APP 后台登录方案：

1、用户第一次输入账户密码登录之后，服务器为其提供一个钥匙

2、以后用户每次需要进入直接使用钥匙。

3、用户决定外出一段时间，咋把钥匙交换服务器销毁。

 

转换成计算机中，用户拿到钥匙的操作：

当用户拿到钥匙之后，将钥匙保存起来，下次再进行登录的时候，将token （钥匙）值传递给服务器，服务器查找用户ID所匹配的token ，对比相同，则允许用户进入

 

当用户退出登录的时候，APP后台把这个用户对应的Token字符串删除  销毁钥匙

 

弊端：身份验证依赖token，一旦用户泄露了URL，获取token,就相当于获取到了钥匙。

 

 

三、APP通信安全

1、URL 签名

身份验证是依赖于token字符串，如果用户泄露了自己的URL，那么token也会被黑客窃取  使用。  （在网络上传播token的方案）

URL签名就是不在网络上传播token的方案

形成新的sign = md5("test.com/user/info?token=dklfj92fs2uvl") = xxxxxxxxxxxxxxxxxxxxxxx;

于是，API请求后加上URL签名sign和用户ID就可以使token不需要附在URL上

后台就会根据这个URL 后，根据相对应的算法获取到token，发现token和数据库里用户ID 相对应的token相同，表示验证通过

 

URL 签名的验证流程图

2. url签名的不足之处

　　url签名有两个缺点：


　　1.当用户第一次登录后token是明文返回，有被截取的风险


　　2. url签名只能保护token值却没法保护其他敏感数据,例如，当用户更新自己的个人信息时，所有的信息在传输过程中应该是被加密的.

AES加密，

整个过程如下：

1、用户名密码 + https + url签名（url+时间戳+随机字串）链接+请求时间+保唯一的字串
2、服务器返回token：aes(约定算法)=》（token+随机secret(就取上面那个签名中的16位)）
3、app保存token后，以后每次机通信都通过  aes (token + 内容)  传输

转自：http://blog.csdn.net/newjueqi/article/details/44177063。

转载于:https://www.cnblogs.com/10-8-2016-song/p/7235067.html