1）基于server端session的管理办法
2）cookie-base的管理办法
3）token-base的管理办法
这些内容可以帮助加深对web中用户登录机制的理解，对实际项目开拓也有参考代价，欢迎阅读与示正。
1. 基于server端session的管理在早期web运用中，常日利用做事端session来管理用户的会话。快速理解做事端session:
1) 做事端session是用户第一次访问运用时，做事器就会创建的工具，代表用户的一次会话过程，可以用来存放数据。做事器为每一个session都分配一个唯一的sessionid，以担保每个用户都有一个不同的session工具。
2）做事器在创建完session后，会把sessionid通过cookie返回给用户所在的浏览器，这样当用户第二次及往后向做事器发送要求的时候，就会通过cookie把sessionid传回给做事器，以便做事器能够根据sessionid找到与该用户对应的session工具。
3）session常日有失落效韶光的设定，比如2个小时。当失落效韶光到，做事器会销毁之前的session，并创建新的session返回给用户。但是只要用户在失落效韶光内，有发送新的要求给做事器，常日做事器都会把他对应的session的失落效韶光根据当前的要求韶光再延长2个小时。
4）session在一开始并不具备会话管理的浸染。它只有在用户登录认证成功之后，并且往sesssion工具里面放入了用户登录成功的凭据，才能用来管理会话。管理会话的逻辑也很大略，只要拿到用户的session工具，看它里面有没有登录成功的凭据，就能判断这个用户是否已经登录。当用户主动退出的时候，会把它的session工具里的登录凭据清掉。以是在用户登录前或退出后或者session工具失落效时，肯定都是拿不到须要的登录凭据的。
以长进程可大略利用流程图描述如下：
主流的web开拓平台（java,.net,php）都原生支持这种会话管理的办法，而且开拓起来很大略，相信大部分后端开拓职员在入门的时候都理解并利用过它。它还有一个比较大的优点便是安全性好，由于在浏览器端与做事器端保持会话状态的媒介始终只是一个sessionid串，只要这个串够随机，攻击者就不能轻易伪装他人的sessionid进行操作；除非通过CSRF或http挟制的办法，才有可能伪装别人进行操作；纵然伪装成功，也必须被伪装的用户session里面包含有效的登录凭据才行。但是在真正决定用它管理会话之前，也得根据自己的运用情形考虑以下几个问题：
1）这种办法将会话信息存储在web做事器里面，以是在用户同时在线量比较多时，这些会话信息会霸占比较多的内存；
2）当运用采取集群支配的时候，会碰着多台web做事器之间如何做session共享的问题。由于session是由单个做事器创建的，但是处理用户要求的做事器不一定是那个创建session的做事器，这样他就拿不到之前已经放入到session中的登录凭据之类的信息了；
3）多个运用要共享session时，除了以上问题，还会碰着跨域问题，由于不同的运用可能支配的主机不一样，须要在各个运用做好cookie跨域的处理。
针对问题1和问题2，我见过的办理方案是采取redis这种中间做事器来管理session的增编削查，一来减轻web做事器的包袱，二来办理不同web做事器共享session的问题。针对问题3，由于做事真个session依赖cookie来通报sessionid，以是在实际项目中，只要办理各个项目里面如何实现sessionid的cookie跨域访问即可，这个是可以实现的，便是比较麻烦，前后端有可能都要做处理。
如果不考虑以上三个问题，这种管理办法比较值得利用，尤其是一些小型的web运用。但是一旦运用将来有扩展的必要，那就得谨慎对待前面的三个问题。如果真要在项目中利用这种办法，推举结合单点登录框架如CAS一起用，这样会使运用的扩展性更强。
2. cookie-based的管理办法由于前一种办法会增加做事器的包袱和架构的繁芜性，所往后来就有人想出直接把用户的登录凭据直接存到客户真个方案，当用户登录成功之后，把登录凭据写到cookie里面，并给cookie设置有效期，后续要求直接验证存有登录凭据的cookie是否存在以及凭据是否有效，即可判断用户的登录状态。利用它来实现会话管理的整体流程如下：
1）用户发起登录要求，做事端根据传入的用户密码之类的身份信息，验证用户是否知足登录条件，如果知足，就根据用户信息创建一个登录凭据，这个登录凭据大略来说便是一个工具，最大略的形式可以只包含用户id，凭据创建韶光和过期韶光三个值。
2）做事端把上一步创建好的登录凭据，先对它做数字署名，然后再用对称加密算法做加密处理，将署名、加密后的字串，写入cookie。cookie的名字必须固定（如ticket），由于后面再获取的时候，还得根据这个名字来获取cookie值。这一步添加数字署名的目的是防止登录凭据里的信息被修改，由于一旦信息被修改，那么下一步做署名验证的时候肯定会失落败。做加密的目的，是防止cookie被别人截取的时候，无法轻易读到个中的用户信息。
3）用户登录后发起后续要求，做事端根据上一步存登录凭据的cookie名字，获取到干系的cookie值。然后先做解密处理，再做数字署名的认证，如果这两步都失落败，解释这个登录凭据造孽；如果这两步成功，接着就可以拿到原始存入的登录凭据了。然后用这个凭据的过期韶光和当前韶光做比拟，判断凭据是否过期，如果过期，就须要用户再重新登录；如果未过期，则许可要求连续。
这种办法最大的优点便是实现了做事真个无状态化，彻底移除了做事端对会话的管理的逻辑，做事端只须要卖力创建和验证登录cookie即可，无需保持用户的状态信息。对付第一种办法的第二个问题，用户会话信息共享的问题，它也能很好办理：由于如果只是同一个运用做集群支配，由于验证登录凭据的代码都是一样的，以是不管是哪个做事器处理用户要求，总能拿到cookie中的登录凭据来进行验证；如果是不同的运用，只要每个运用都包含相同的登录逻辑，那么他们也是能轻易实现会话共享的，不过这种情形下，登录逻辑里面数字署名以及加密解密要用到的密钥文件或者密钥串，须要在不同的运用里面共享，总而言之，便是须要算法完备保持同等。
这种办法由于把登录凭据直接存放客户端，并且须要cookie传来传去，以是它的缺陷也比较明显：
1）cookie有大小限定，存储不了太多数据，以是假如登录凭据存的过多，导致加密署名后的串太长，就会引发别的问题，比如其它业务场景须要cookie的时候，就有可能没那么多空间可用了；以是用的时候得谨慎，得不雅观察实际的登录cookie的大小；比如太长，就要考虑是非是数字署名的算法太严格，导致署名后的串太长，那就适当调度署名逻辑；比如如果一开始用4096位的RSA算法做数字署名，可以考虑换成1024、2048位；
2）每次传送cookie，增加了要求的数量，对访问性能也有影响；
3）也有跨域问题，毕竟还是要用cookie。
比较起第一种办法，cookie-based方案明显还是要好一些，目前好多web开拓平台或框架都默认利用这种办法来做会话管理，比如php里面yii框架，这是我们团队后端目前用的，它用的便是这个方案，以上提到的那些登录逻辑，框架也都已经封装好了，实际用起来也很大略；asp.net里面forms身份认证，也是这个思路，这里有一篇好文章把它的实现细节都说的很清楚：
http://www.cnblogs.com/fish-li/archive/2012/04/15/2450571.html
前面两种会话管理办法由于都用到cookie，不适宜用在native app里面：native app不好管理cookie，毕竟它不是浏览器。这两种方案都不适宜用来做纯api做事的登录认证。要实现api做事的登录认证，就要考虑下面要先容的第三种会话管理办法。
3. token-based的管理办法这种办法从流程和实现上来说，跟cookie-based的办法没有太多差异，只不过cookie-based里面写到cookie里面的ticket在这种办法下称为token，这个token在返回给客户端之后，后续要求都必须通过url参数或者是http header的形式，主动带上token，这样做事端吸收到要求之后就能直接从http header或者url里面取到token进行验证：
这种办法不通过cookie进行token的通报，而是每次要求的时候，主动把token加到http header里面或者url后面，以是纵然在native app里面也能利用它来调用我们通过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运用里面，会话管理的安全性始终是最主要的安全问题，这个对用户的影响极大。
首先从会话管理凭据来说，第一种办法的会话凭据仅仅是一个session id，以是只要这个session id足够随机，而不是一个自增的数字id值，那么其它人就不可能轻易地伪装别人的session id进行操作；第二种办法的凭据（ticket）以及第三种办法的凭据（token）都是一个在做事端做了数字署名，和加密处理的串，以是只要密钥不透露，别人也无法轻易地拿到这个串中的有效信息并对它进行修改。总之，这三种会话管理办法的凭据本身是比较安全的。
然后从客户端和做事真个http过程来说，当别人截获到客户端要求中的会话凭据，就能拿这个凭据伪装原用户，做一些造孽操作，而做事器也认不出来。这种安全问题，可以大略采取https来办理，虽然可能还有http挟制这种更高程度的威胁存在，但是我们从代码能做的戒备，确实也便是这个层次了。
末了的安全问题便是CSRF（跨站要求假造）。这个跟代码有很大关系，实质上它便是代码的漏洞，只不过一样平常情形下这些漏洞，作为开拓职员都不随意马虎创造，只有那些一门心思想搞些事情的人才会专门去找这些漏洞，以是这种问题的戒备更多地还是依赖于开拓职员对这种攻击办法的理解，包括常见的攻击形式和应对方法。不管凭据信息本身多么安全，别人利用CSRF，就能拿到别人的凭据，然后用它伪装别人进行造孽操作，以是有韶光还真得多去理解下它的干系资料才行。举例来说，如果我们把凭据直接放到url后面进行通报，就有可能成为一个CSRF的漏洞：当恶意用户在我们的运用内上传了1张引用了他自己网站的图片，当正常的用户登录之后访问的页面里面包含这个图片的时候，由于这个图片加载的时候会向恶意网站发送get要求；当恶意网站收到要求的时候，就会从这个要求的Reffer header里面看到包含这个图片的页面地址，而这个地址恰好包含了正常用户的会话凭据；于是恶意用户就拿到了正常用户的凭据；只要这个凭据还没失落效，他就能用它伪装用户进行造孽操作。
5. 总结前面这三种办法，各自有各自的优点及利用场景，我以为没有哪个是最好的，做项目的时候，根据项目将来的扩展情形和架构情形，才能决定用哪个是最得当的。本文的目的也便是想先容这几种办法的事理，以便节制web运用中登录验证的关键成分。
作为一个前端开拓职员，本文虽然先容了3种会话管理的办法，但是与前端关系最紧密的还是第三种办法，毕竟现在前端开拓SPA运用以及hybrid运用已经非常盛行了，以是节制好这个办法的认证过程和利用办法，对前端来说，显然是很有帮助的。好在这个办法的技能实在早就有很多实现了，而且还有现成的标准可用，这个标准便是JWT(json-web-token)。
JWT本身并没有做任何技能实现，它只是定义了token-based的管理办法该如何实现，它规定了token的该当包含的标准内容以及token的天生过程和方法。目前实现了这个标准的技能已经有非常多：
更多可参阅：https://jwt.io/#libraries-io
原文：https://www.cnblogs.com/lyzg/p/6067766.HTML
