Java识堂▲还有这么多解决方案，用户登陆除了cookie和session( 三 )

http://www.cnblogs.com/fish-li/archive/2012/04/15/2450571.html
前面两种会话管理方式因为都用到cookie ，不适合用在nativeapp里面：nativeapp不好管理cookie ，毕竟它不是浏览器。这两种方案都不适合用来做纯api服务的登录认证。要实现api服务的登录认证，就要考虑下面要介绍的第三种会话管理方式。
3.token-based的管理方式这种方式从流程和实现上来说，跟cookie-based的方式没有太多区别，只不过cookie-based里面写到cookie里面的ticket在这种方式下称为token ，这个token在返回给客户端之后，后续请求都必须通过url参数或者是httpheader的形式，主动带上token ，这样服务端接收到请求之后就能直接从httpheader或者url里面取到token进行验证：

文章图片
这种方式不通过cookie进行token的传递，而是每次请求的时候，主动把token加到httpheader里面或者url后面，所以即使在nativeapp里面也能使用它来调用我们通过web发布的api接口。 app里面还要做两件事情：
1）有效存储token ，得保证每次调接口的时候都能从同一个位置拿到同一个token；
2）每次调接口的的代码里都得把token加到header或者接口地址里面。
看起来麻烦，其实也不麻烦，这两件事情，对于app来说，很容易做到，只要对接口调用的模块稍加封装即可。
这种方式同样适用于网页应用， token可以存于localStorage或者sessionStorage里面，然后每发ajax请求的时候，都把token拿出来放到ajax请求的header里即可。不过如果是非接口的请求，比如直接通过点击链接请求一个页面这种，是无法自动带上token的。所以这种方式也仅限于走纯接口的web应用。
这种方式用在web应用里也有跨域的问题，比如应用如果部署在a.com ， api服务部署在b.com ，从a.com里面发出ajax请求到b.com ，默认情况下是会报跨域错误的，这种问题可以用CORS（跨域资源共享）的方式来快速解决，相关细节可去阅读前面给出的CORS文章详细了解。
这种方式跟cookie-based的方式同样都还有的一个问题就是ticket或者token刷新的问题。有的产品里面，你肯定不希望用户登录后，操作了半个小时，结果ticket或者token到了过期时间，然后用户又得去重新登录的情况出现。这个时候就得考虑ticket或token的自动刷新的问题，简单来说，可以在验证ticket或token有效之后，自动把ticket或token的失效时间延长，然后把它再返回给客户端；客户端如果检测到服务器有返回新的ticket或token ，就替换原来的ticket或token 。
4.安全问题在web应用里面，会话管理的安全性始终是最重要的安全问题，这个对用户的影响极大。
首先从会话管理凭证来说，第一种方式的会话凭证仅仅是一个sessionid ，所以只要这个sessionid足够随机，而不是一个自增的数字id值，那么其它人就不可能轻易地冒充别人的sessionid进行操作；第二种方式的凭证（ticket）以及第三种方式的凭证（token）都是一个在服务端做了数字签名，和加密处理的串，所以只要密钥不泄露，别人也无法轻易地拿到这个串中的有效信息并对它进行篡改。总之，这三种会话管理方式的凭证本身是比较安全的。
然后从客户端和服务端的http过程来说，当别人截获到客户端请求中的会话凭证，就能拿这个凭证冒充原用户，做一些非法操作，而服务器也认不出来。这种安全问题，可以简单采用https来解决，虽然可能还有http劫持这种更高程度的威胁存在，但是我们从代码能做的防范，确实也就是这个层次了。
最后的安全问题就是CSRF（跨站请求伪造）。这个跟代码有很大关系，本质上它就是代码的漏洞，只不过一般情况下这些漏洞，作为开发人员都不容易发现，只有那些一门心思想搞些事情的人才会专门去找这些漏洞，所以这种问题的防范更多地还是依赖于开发人员对这种攻击方式的了解，包括常见的攻击形式和应对方法。不管凭证信息本身多么安全，别人利用CSRF ，就能拿到别人的凭证，然后用它冒充别人进行非法操作，所以有时间还真得多去了解下它的相关资料才行。举例来说，假如我们把凭证直接放到url后面进行传递，就有可能成为一个CSRF的漏洞：当恶意用户在我们的应用内上传了1张引用了他自己网站的图片，当正常的用户登录之后访问的页面里面包含这个图片的时候，由于这个图片加载的时候会向恶意网站发送get请求；当恶意网站收到请求的时候，就会从这个请求的Refferheader里面看到包含这个图片的页面地址，而这个地址正好包含了正常用户的会话凭证；于是恶意用户就拿到了正常用户的凭证；只要这个凭证还没失效，他就能用它冒充用户进行非法操作。