39.App中用户验证方案

注：这篇文章为15.app后端怎么设计用户登录方案的修改版，以前的这篇博客写得太简单了，弄得很多同学理解不了，趁着写书《App后台开发运维和架构实践》的机会，把这篇文章重写了。

App操作中经常涉及用户登录操作，用户登录就需要使用用户名和密码。为了安全起见，在登录的过程中暴露密码的机会越少越好。

登录过程中怎样才能最大程度地避免泄露用户的密码的可能呢？

用户登录后，App后台怎么去验证和维持用户的登录状态呢？

本节提供了一套用户登录的解决方案以供读者参考。

使用HTTPS协议

避免信息的泄露，最基本的方案是所有涉及安全性的API请求都必须使用HTTPS协议。

HTTPS协议是“HTTP协议”和“SSL/TLS协议”的组合。

SSL是“Secure Sockets Layer”的缩写，中文称为“安全套接层”，其是20世纪90年代中期由网景公司设计的。原来在互联网上使用的 HTTP 协议是明文，存在很多缺点（比如传输内容会被偷窥和篡改），发明 SSL协议是为了解决这些问题。到了1999年，SSL协议因为其应用广泛已经成为互联网上的事实标准，IETF 就在1999年把SSL协议标准化。SSL协议标准化之后的名称改为TLS（Transport Layer Security）协议，中文称为“传输层安全协议”。习惯上把这两者并列称呼（SSL/TLS），因为这两者可以视作同一个东西的不同阶段。

可以把HTTPS大致理解为“HTTP over SSL”或“HTTP over TLS”。其是一个安全通信通道，基于HTTP开发，用于在客户计算机和App后台之间交换信息。其使用安全套接字层(SSL)进行信息交换，简单来说其是HTTP的安全版。HTTPS实际上应用了安全套接字层（SSL）作为HTTP应用层的子层。

HTTPS的模型如下图所示。

读者看看支付宝涉及登录和支付的页面，URL都是以HTTPS开头，这就意味通信是使用HTTPS。国内主流开放平台的API，例如新浪微博、腾讯等，API请求都是以HTTPS开头。

HTTPS是业界常用的安全协议，支付宝登录的页面就是使用了HTTPS协议，如下图所示。

基本的用户登录方案

传统Web网站使用Cookie+Session保持用户的登录状态，那么在App后台怎么实现类似的功能呢？在App后台怎么避免每次验证用户身份都需要传输用户名和密码呢？

解决上面的问题，可以参考下面例子。
把App后台想象为一个房间，里面有个房间管理员。同时房间门有一把锁，这把锁有两种打开方式。

• 输入了这把锁上注册的用户名和密码。
• 用房间管理员提供的钥匙。

用户进入这个房间的流程如下。
（1）用户第一次输入锁上注册的用户名和密码打开这把锁后进入房间，找到房间管理员，让其提供一把钥匙。

（2）以后用户每次需要进入这个房间用这把钥匙就行，不用担心旁边有人偷看到自己的用户名和密码，从而导致用户名和密码的泄露。

（3）用户决定一段时间内不再进入这个房间，又怕钥匙被偷，进入房间后把钥匙还给管理员，让管理员把钥匙销毁。

其中（1）就是用户的登录操作；（2）就是用户登录后验证身份的操作；（3）就是用户退出登录的操作。

把上面的例子转换为计算机的操作，描述如下。

（1）App后台接收到App发送的用户名和密码后，验证用户名和密码是否正确。如果错误则返回错误信息。如果App后台验证正确，生成一个随机的不重复的token字符串（例如“daf32da456hfdh”），token字符串作为用户的唯一标识（token就是上面例子中提到的钥匙）。在Redis中建立token字符串和用户信息的对应关系，例如，把token字符串“daf32da456hfdh”和id为“5”的用户对应。注意：Redis 的hash数据结构将会在“7.2.2 hash—存储对像的数据”这节中详细讲解。

（2）App后台把token字符串和用户信息返回给App，App保存这些数据作为以后身份验证的必备数据。生成token的流程如下图所示。

（3）需要验证用户身份的操作必须要把token字符串传给App后台验证身份。

例如，“test.com/user/update”是更新用户的信息的API，这个API必须验证用户身份，当调用API“test.com/user/update”时，把token字符串“daf32da456hfdh”附在URL上，变成“test.com/user/update?token=daf32da456hfdh”。

当App后台接收到这个API请求时，权限设置中要求验证用户身份，于是取出参数中token的值“daf32da456hfdh”，在（1）中建立的token字符串和用户信息的对应关系中查找，如果没发现这个token值，则返回验证失败的信息，如果发现这个token值，则获取这个用户的信息，进行相关的更新操作。

注意：这个方案并不是十分安全，身份验证依赖token字符串。如果用户泄露了URL，那token也泄露了，这相当于钥匙被黑客复制了一份。在下一篇“ App通信安全”中将描述一个防止token在通信中泄露的方案。

本章内容摘录自本人出版的书籍《App后台开发运维和架构实践》

《App后台开发运维和架构实践》的购买链接

京东
当当
亚马逊
互动出版网
天猫

打开链接 app后端设计–总目录 ，能查看本人发表过的所有原创“app后端”文章。

【作者】曾健生
【QQ】190678908
【微信公众号】 appbackend
【新浪微博】 @newjueqi
【博客】http://blog.csdn.net/newjueqi