15.app后端怎么设计用户登录方案
在很多app中，都需要用户的登录操作。登录，就需要用到用户名和密码。为了安全起见，暴露明文密码的次数越少越好。怎么能最大程度避免泄露用户的密码呢？在登录后，app后端怎么去验证和维持用户的登录状态呢？在本文中，给出了一套用户登录的解决方案，以供大家参考。
避免信息的泄露，最简单的方案是所有涉及到安全性的api请求，都必须要使用https协议。
HTTPS（Secure Hypertext Transfer Protocol）安全超文本传输协议
它是一个安全通信通道，它基于HTTP开发，用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是HTTP的安全版。它是由Netscape开发并内置于其浏览器中，用于对数据进行压缩和解压操作，并返回网络上传送回的结果。HTTPS实际上应用了Netscape的安 全全套接字层（SSL）作为HTTP应用层的子层。
http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。
注意了，https协议需要到ca申请证书，一般免费证书很少，需要交费。
我们可以看看所有大型网站，例如京东，淘宝，支付宝，涉及到登录和支付的页面，url都是以https开头，这就意味着，这次通讯是使用https。开放平台的api，例如新浪微博，腾讯等，api请求都是以https开头的。https是业界常用的保证安全性的协议。
因此，涉及安全问题的api，都应该使用https协议。虽然，https为了保证安全性，在效率上是比http协议低。
在传统的web网站中，可以使用cookie+session来实现用户的登录维护，那么在app后端，可以怎么实现呢？
在app后端，怎么避免每次验证用户身份都需要传输用户名和密码呢？
一个生活的模型就是：
假设服务器是个房间，里面有个房间管理员，房间上的门有把锁，这把锁有两种打开方式:
1. 输入了这把锁上注册的用户名和密码，就能打开
2. 用房间管理员提供的钥匙打开
a.当第一次使用用户名和密码打开了这把锁后，进入房间，找到房间管理员，让他提供一把钥匙。
b.那以后每次需要进入这个房间，就用这把钥匙就行了，不用担心旁边有人偷看到自己的用户名和密码.
c.决定有一段时间不进入这个房间，又怕钥匙被偷，就进入房间里，把钥匙还给管理员，让管理员把钥匙毁灭
a就是登录的操作，ｂ就是验证身份的操作，ｃ就是退出登录的操作.
理论版的描述如下：
(1) 服务器接收到app发送的用户名和密码后，验证用户名和密码是否正确。
如果错误则返回错误信息。
如果验证正确，生成一个随机的不重复的token字符串（例如"daf32da456hfdh"），在redis或memcache中维护一个映视表，建立token字符串和用户信息的对应关系表，例如，把token字符串"daf32da456hfdh"和用户id"5"对应起来。
(2) 服务器把token字符串返回给app，app把这个token字符串保存起来，作为登录的验证。
(3) 当需要验证用户身份的操作时，必须要把token字符串传给服务器验证身份。
例如，api "test.com/user/update"是更新用户的信息，必须要验证用户的身份.当调用api "test.com/user/update"时，把token字符串"daf32da456hfdh"放在url上，变成"test.com/user/update?token=daf32da456hfdh" .
当服务器接收到这个api请求，知道要验证用户身份的，于是，就把参数中token的值"daf32da456hfdh"取出来，在(1)中建立的token字符串和用户信息的对应关系表查找，如果发现没这个token值的，则返回验证失败的信息。如果发现有这个token值，则获取这个用户的信息,进行相关的更新操作。
(4) 当用户退出登录时，需要通过调用api，让服务器把这个用户对于的token字符串删除.
例如，api "test.com/user/logout"是退出登录的api,也要验证用户身份， 则调用"test.com/user/logout?token=daf32da456hfdh" 。当服务器接到退出登录的api请求时，在(1)中建立的token字符串和用户信息的对应关系表查找token字符串，把token和用户信息都删除即可。
【QQ】190678908
【app后端qq群】254659220
【微信公众号】 appbackend
【新浪微博】 @newjueqi
【博客】http://blog.csdn.net/newjueqi
1. 保证登录的安全性，最起码要使用https协议
避免信息的泄露，最简单的方案是所有涉及到安全性的api请求，都必须要使用https协议。
HTTPS（Secure Hypertext Transfer Protocol）安全超文本传输协议
它是一个安全通信通道，它基于HTTP开发，用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是HTTP的安全版。它是由Netscape开发并内置于其浏览器中，用于对数据进行压缩和解压操作，并返回网络上传送回的结果。HTTPS实际上应用了Netscape的安 全全套接字层（SSL）作为HTTP应用层的子层。
http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。
注意了，https协议需要到ca申请证书，一般免费证书很少，需要交费。
我们可以看看所有大型网站，例如京东，淘宝，支付宝，涉及到登录和支付的页面，url都是以https开头，这就意味着，这次通讯是使用https。开放平台的api，例如新浪微博，腾讯等，api请求都是以https开头的。https是业界常用的保证安全性的协议。
因此，涉及安全问题的api，都应该使用https协议。虽然，https为了保证安全性，在效率上是比http协议低。
2. 基本的用户登录方案
在传统的web网站中，可以使用cookie+session来实现用户的登录维护，那么在app后端，可以怎么实现呢？
在app后端，怎么避免每次验证用户身份都需要传输用户名和密码呢？
一个生活的模型就是：
假设服务器是个房间，里面有个房间管理员，房间上的门有把锁，这把锁有两种打开方式:
1. 输入了这把锁上注册的用户名和密码，就能打开
2. 用房间管理员提供的钥匙打开
a.当第一次使用用户名和密码打开了这把锁后，进入房间，找到房间管理员，让他提供一把钥匙。
b.那以后每次需要进入这个房间，就用这把钥匙就行了，不用担心旁边有人偷看到自己的用户名和密码.
c.决定有一段时间不进入这个房间，又怕钥匙被偷，就进入房间里，把钥匙还给管理员，让管理员把钥匙毁灭
a就是登录的操作，ｂ就是验证身份的操作，ｃ就是退出登录的操作.
理论版的描述如下：
(1) 服务器接收到app发送的用户名和密码后，验证用户名和密码是否正确。
如果错误则返回错误信息。
如果验证正确，生成一个随机的不重复的token字符串（例如"daf32da456hfdh"），在redis或memcache中维护一个映视表，建立token字符串和用户信息的对应关系表，例如，把token字符串"daf32da456hfdh"和用户id"5"对应起来。
(2) 服务器把token字符串返回给app，app把这个token字符串保存起来，作为登录的验证。
(3) 当需要验证用户身份的操作时，必须要把token字符串传给服务器验证身份。
例如，api "test.com/user/update"是更新用户的信息，必须要验证用户的身份.当调用api "test.com/user/update"时，把token字符串"daf32da456hfdh"放在url上，变成"test.com/user/update?token=daf32da456hfdh" .
当服务器接收到这个api请求，知道要验证用户身份的，于是，就把参数中token的值"daf32da456hfdh"取出来，在(1)中建立的token字符串和用户信息的对应关系表查找，如果发现没这个token值的，则返回验证失败的信息。如果发现有这个token值，则获取这个用户的信息,进行相关的更新操作。
(4) 当用户退出登录时，需要通过调用api，让服务器把这个用户对于的token字符串删除.
例如，api "test.com/user/logout"是退出登录的api,也要验证用户身份， 则调用"test.com/user/logout?token=daf32da456hfdh" 。当服务器接到退出登录的api请求时，在(1)中建立的token字符串和用户信息的对应关系表查找token字符串，把token和用户信息都删除即可。
注意：这个方案并不是十分安全，这个身份验证是依赖于token字符串。如果用户泄漏了自己的url, 那很大程度上token也被别人泄漏了，就相当于钥匙被人复制了一份。在下篇的通讯安全中，会描述一个防止token在通讯中泄漏的方案。
---------------------------------------------------------------------------------------------------------------------------
打开链接 app后端系列文章总目录 总目录 ，能查看本人发表过的所有原创“app后端”文章。
【作者】曾健生
【QQ】190678908
【app后端qq群】254659220
【微信公众号】 appbackend
【新浪微博】 @newjueqi
【博客】http://blog.csdn.net/newjueqi