原来经常用oauth2 的password方案来做登录，自己给自己app做授权没毛病呀，但后面一下有点不对，这里应该是有问题的。于是学习了原生app登录的方案。并学习一系列登录有关知识。特此记录，这是第一篇。
PS:注意，标题中的token即不是oauth2 中的toekn。也不是JSON WEB Token(JWT)中的token
文章目录
一般情况下，登录方案主要解决三个问题1 登录 2 登录保持 3 登出。
注意以下所有登录方案的 登录及涉及鉴权API都是都是建立https基础上。
1 web端-session cookies方案
Session 是存放在服务器端的，类似于Session结构来存放用户数据，当浏览器 第一次发送请求时，服务器自动生成了一个Session和一个Session ID用来唯一标识这个Session，并将其通过响应发送到浏览器。当浏览器第二次发送请求，会将前一次服务器响应中的Session ID放在请求中一并发送到服务器上，服务器从请求中提取出Session ID，并和保存的所有Session ID进行对比，找到这个用户对应的Session。
具体实现：
1.1 登录
首先用户通过post请求提交账户密码到服务器，服务器判断正确后生成一个sessionid，并将sessionid与userid等账户信息一起存储到内存性数据库(Redis)中，并将sessionid设置到cookies中响应。
1.2 登录保持
下次浏览器其他请求就可以从cookies中得到sessionid，从而从数据库中得到用户相关信息，则视为登录成功具有响应权限。当然我们应该为sessionid设置有效期。
1.3 登出
登出，则从数据中删除相应sessionid即可，以上即为web端的登录，登录保持，登出 简单的解决方案。
2 APP端方案 -token
同理，对于app对于APP端，同样可以采取类似于session的方式实现。嗯，token也是就是sessionid的另一名字。
2.1 APP登录
APP登录也可以生成一个key用来标识该用户登录成功,因为app没有cookies的概念，所以这个key(sessionid)不能在存储到cookies中了。而是通过相应返回给了app，由app存储，现在它的名字又叫token了。
2.2 登录保持
每次app请求需要验证登录状态的api就带上这个token(请放在header 或body),而服务器同样从redis 通过该token得到相应的用户信息，来判断登录。登出过程同样
2.3 登出
同样从redis中删除相应token即可实现登出效果。
PS:注意，这里token即不是oauth2 中的toekn。也不是JSON WEB Token(JWT)中的token(这东西很难实现登出)。
示意图：
3 安全性分析
在网上看到很多花里花哨的RSA加密方案来确保第一次登录账户密码及后续的token不被拦截泄漏。如果登录和后续有权限操作的API均采用https，则同样是解决上诉问题(同样是RSA加密)，当然服务器数据库泄漏和app本地token被盗，这种风险就不在本文讨论之列。
4 涉及到授权的问题
如果涉及到向三方应用授权，可能就需要部署oauth2授权协议。虽然同样可以用oauth2 的password为本身app进行授权，但如果oauth2一般情况是没有部署在redis这种内存性数据库中。每次请求都涉及到鉴权都会操作数据库，会极大的提高服务器负载。