首页 > 代码库 > 用户验证方案

用户验证方案

一、使用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。

用户验证方案