首页 > 代码库 > 用户验证方案
用户验证方案
一、使用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。
用户验证方案